Using Apache with SELinux on Fedora [LWN.net]

Using Apache with SELinux on Fedora

Posted Nov 17, 2004 23:03 UTC (Wed) by walters (subscriber, #7396) [Link]

...this document is a good introduction to the complexities of making SELinux work with even a single system daemon.

Note that most of the other daemons protected in the targeted policy one doesn't configure very much, like ntpd, syslog, and portmap. Apache is far and away unique in the amount of configurablity. We've seen very few people having problems with ntpd or syslog; in fact, I doubt most people are even aware that SELinux protects those daemons.

Using Apache with SELinux on Fedora

Posted Nov 18, 2004 0:06 UTC (Thu) by jamesm (guest, #2273) [Link]

Indeed, there are entire books devoted to Apache configuration. SELinux reflects the underlying complexity of what it's protecting. There is no magic bullet, sorry.

SELinux is too complex! Systrace is simpler!

Posted Nov 18, 2004 2:30 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link]

I hate to keep repeating myself but it is frustrating that Fedora has chosen SELinux (almost certainly for marketing reasons --- led by the nose ring towards Red Hat's future plans for their enterprise offerings).

Systrace is so much simpler, conceptually, that it's a sham not to include it. Also the fact that it's available on the BSDs and even MacOS X (and the possibility of adding it to an open source Solaris in the near future) could make it the first truly portable kernel security enhancement. This means that time spent by systems administrators on learning it, in depth, will be usable throughout their careers,rather than being mired in an OS specific niche!

JimD

SELinux is too complex! Systrace is simpler!

Posted Nov 18, 2004 21:59 UTC (Thu) by walters (subscriber, #7396) [Link]

I hate to keep repeating myself but it is frustrating that Fedora has chosen SELinux (almost certainly for marketing reasons...

No; there are a wide variety of reasons. To give one example, Fedora has a policy of not deviating much from upstream. SELinux is in the mainstream kernel.

Systrace is so much simpler, conceptually, that it's a sham not to include it.

Systrace is not quite the same thing. It suffers from implementation issues such as not using LSM, and taking the performance hit of going out to userspace for every system call. Conceptually those are fixable. What is harder to fix are is architectural issues. For example, from the usr_bin_ssh policy, you see:

native-kill: permit

In other words, ssh is, as far as I can tell, permitted to kill any other process. Since sshd runs as uid 0, a compromised ssh can terminate any other process on your machine.

In the SELinux TE language, you can express that for example, sshd is only allowed to send sigkill to a process running in the same domain. Another example might be Postfix; you can allow postfix_master_t to send sigkill to postfix_smtpd_t and postfix_smtp_t, but not cupsd_t.

native-fsread: filename eq "/var/run/ld.so.hints" then permit

The filename-based approach suffers from tranquility issues; in other words, nothing ensures that /var/run/ld.so.hints has not been replaced by another file in between when the userspace Systrace manager OKs the access but before the kernel reads the response.

There are other problems with Systrace that SELinux solves as well, but these are the major ones I see on a first glance at Systrace.