On 03/19/2013 03:39 PM, Daniel Neuberger wrote:
On 03/19/2013 02:00 PM, Stephen Smalley wrote:
Normally you would only label the entrypoint executable for syslogd
(i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not
helper programs internally called by it. Anything else would get
labeled with a different type, which could just be bin_t for libexec
files. But you may also need to add an allow rule via local policy
module to allow this if it is new behavior for syslog-ng.
Also, what you tried to do (in labeling the libexec file with syslogd_t)
isn't desirable because it conflates a domain type (syslogd_t) used for
processes with a file type (e.g. syslogd_exec_t, bin_t, ...). The only
case where a domain type should appear on a "file" is for the /proc/pid
entries associated with a process in that domain. It shouldn't be used
on regular files.
Thanks! Using your advice, I was able to get it working by adding the
below to the policy:
----------------------------
require {
type syslogd_t;
type var_t;
type bin_t;
class process getsched;
class file { read execute execute_no_trans };
class dir write;
}
#============= syslogd_t ==============
allow syslogd_t bin_t:file { read execute execute_no_trans };
allow syslogd_t self:process getsched;
allow syslogd_t var_t:dir write;
----------------------------
Any recommendations on whether that seems like the right solution? I'm
new to writing policy, but it seems too permissive to me. Anyone have a
reference that would help me to recognize the difference between a good
policy and something that just allows whatever to make it work?
Also, why does nosuid suppress domain transitions? I couldn't find any
details on Google or in the RHEL docs.
Thanks again for all the help.
Not sure why you need the getsched rule; that should already be allowed.
The var_t rule seems too broad; I suspect you should have a more
specific type on the directory in question (would have to see the audit
messages).
We followed the existing convention that nosuid disables security state
changes for executables in that filesystem and applied it to SELinux
security contexts in addition to the existing restrictions on
setuid/setgid executables. If you didn't trust setuid/setgid bits from
that filesystem, why would you trust security contexts from it? But in
retrospect, it might have been better to have a separate flag for that
purpose.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
