On 03/19/2013 04:01 PM, Stephen Smalley wrote:
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.
Interesting. I guess I can see both sides. In our case, we have a
separate requirement to specify nosuid, but now we have to justify not
doing so in order to keep SELinux working. So it makes sense to me from
a technical standpoint, but decisions aren't always made that way. So I
agree that having a separate flag would be useful to allow more
flexibility. Thanks for the explanation.
One more question. I tried putting my semanage calls to update the file
contexts in a custom rpm depending on the selinux-policy-targeted rpm.
In the rpm scriptlet, I first made all the semanage calls and then
called restorecon on the appropriate paths so that the new file contexts
would be applied without having to relabel the entire file system. This
all works except when the rpm is installed by anaconda during a
kickstart install. In that case, I have to run restorecon again during
kspost or manually after the install. Any ideas why or suggestions for
a better solution?
For those interested, here is a summary of the complete solution to get
the syslog-ng daemon as installed by the balabit rpms on RHEL 5 working
with selinux:
* Make sure nosuid is not set on /opt
* Update file contexts:
/usr/sbin/semanage fcontext -a -t syslogd_script_exec_t
/etc/init.d/syslog-ng
/usr/sbin/semanage fcontext -a -t syslogd_exec_t
/opt/syslog-ng/sbin/syslog-ng
/usr/sbin/semanage fcontext -a -t var_run_t /opt/syslog-ng/var/run
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t
/opt/syslog-ng/var/syslog-ng.persist
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t
/opt/syslog-ng/var/run/syslog-ng.pid
/usr/sbin/semanage fcontext -a -t syslogd_var_lib_t
/opt/syslog-ng/var/run/syslog-ng.ctl
/usr/sbin/semanage fcontext -a -t syslog_conf_t
/opt/syslog-ng/etc/syslog-ng.conf
* Apply changes to file contexts:
restorecon -R /opt/syslog-ng/ /etc/init.d/syslog-ng
* save local.te:
--------------------------------
module sdi_syslog 1.0;
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;
--------------------------------
* Compile and install our local syslog-ng selinux policy:
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -i local.pp
* If you had to update the mount options on /opt, reboot
* Otherwise, run:
rm -f /dev/log
service syslog-ng restart
* Verify that syslog is running in syslogd_t type domain and that
/dev/log is created as type devlog_t
...
FYI, the local policy is probably too permissive as Stephen mentioned in
one of the previous posts. Hopefully, I will find time to fix that
eventually at which point I will try to remember to post an update.
Until then though, this is the best I've got.
Suggestions are welcomed.
Thanks so much for the help!
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
