I updated the policy after I found that there was a bug with starting DHCP and since then I haven't had any issues getting things to work. Things like a CGI script running sendmail to send an email - which used to show up in the audit log, now work fine.
What can I do to see if SELinux is still paying attention?
-Jon
On Wed, 2005-06-22 at 17:41 -0400, Jon August wrote:
I updated the policy after I found that there was a bug with starting DHCP and since then I haven't had any issues getting things to work. Things like a CGI script running sendmail to send an email - which used to show up in the audit log, now work fine.
What can I do to see if SELinux is still paying attention?
You can run 'ps axZ | grep processname' to see the security context that a process is running under. For example,
[root@nexus walters]# ps axZ | grep httpd root:system_r:httpd_t 2723 ? Ss 0:00 /usr/sbin/httpd
If you see httpd_t then you can be pretty sure your CGI script is confined. The only way it could not be, off the top of my head, is if you have a script labeled with the type httpd_unconfined_script_exec_t.
httpd is running with type:
root:system_r:unconfined_t
What does this mean? Is httpd a vulnerability on this machine?
On Jun 22, 2005, at 6:35 PM, Colin Walters wrote:
On Wed, 2005-06-22 at 17:41 -0400, Jon August wrote:
I updated the policy after I found that there was a bug with starting DHCP and since then I haven't had any issues getting things to work. Things like a CGI script running sendmail to send an email - which used to show up in the audit log, now work fine.
What can I do to see if SELinux is still paying attention?
You can run 'ps axZ | grep processname' to see the security context that a process is running under. For example,
[root@nexus walters]# ps axZ | grep httpd root:system_r:httpd_t 2723 ? Ss 0:00 /usr/ sbin/httpd
If you see httpd_t then you can be pretty sure your CGI script is confined. The only way it could not be, off the top of my head, is if you have a script labeled with the type httpd_unconfined_script_exec_t.
On Wed, 2005-06-22 at 18:45 -0400, Jon August wrote:
httpd is running with type:
root:system_r:unconfined_t
What does this mean? Is httpd a vulnerability on this machine?
This means that httpd is not confined by the SELinux policy. This means you have less protection against a compromise or misconfiguration of httpd or CGI scripts.
Since the default is for it to be enabled, someone (possibly you) disabled SELinux protection for httpd; you can reenable it by using system-config-securitylevel (or "setsebool -P httpd_disable_trans=false").
Would compiling my own version of apache and installing it myself rather than using yum, for example, to install it result in a unconfined httpd?
On Jun 22, 2005, at 7:29 PM, Colin Walters wrote:
On Wed, 2005-06-22 at 18:45 -0400, Jon August wrote:
httpd is running with type:
root:system_r:unconfined_t
What does this mean? Is httpd a vulnerability on this machine?
This means that httpd is not confined by the SELinux policy. This means you have less protection against a compromise or misconfiguration of httpd or CGI scripts.
Since the default is for it to be enabled, someone (possibly you) disabled SELinux protection for httpd; you can reenable it by using system-config-securitylevel (or "setsebool -P httpd_disable_trans=false").
On Wed, 2005-06-22 at 22:14 -0400, Jon August wrote:
Would compiling my own version of apache and installing it myself rather than using yum, for example, to install it result in a unconfined httpd?
Probably, yes. The way the Fedora Apache SELinux setup works is by /usr/sbin/httpd having the type httpd_exec_t (see ls -Z /usr/sbin/httpd).
If you installed an Apache binary in /usr/local/bin/httpd for example, it might work to do: chcon -t httpd_exec_t /usr/local/bin/httpd
However you may need to change the types of other files as well (e.g. if you use /usr/local/etc/httpd, you should probably: chcon -R -h -t httpd_config_t /usr/local/etc/httpd
An easier (or least more well-tested) route would be to recompile the Fedora SRPM. Even easier and more well-tested would be to find a way to do what you want without compiling your own version of Apache httpd. Why did you do that, anyways?
On Wed, 22 Jun 2005, Colin Walters wrote:
On Wed, 2005-06-22 at 18:45 -0400, Jon August wrote:
httpd is running with type:
root:system_r:unconfined_t
What does this mean? Is httpd a vulnerability on this machine?
This means that httpd is not confined by the SELinux policy. This means you have less protection against a compromise or misconfiguration of httpd or CGI scripts.
Since the default is for it to be enabled, someone (possibly you) disabled SELinux protection for httpd; you can reenable it by using system-config-securitylevel (or "setsebool -P httpd_disable_trans=false").
Strange, on one computer httpd runs with:
root:system_r:httpd_t 11845 ? Ss 0:00 /usr/sbin/httpd but if I do setsebool -P httpd_disable_trans 0 on an other computer I get
[root@flashdance ny]# /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: /usr/sbin/httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: Permission denied [FAILED] On both computers the selinux perms are:
[iocc@flashdance texts]$ ll -Z /lib/libpcre.so.0* lrwxrwxrwx root system_u:object_r:lib_t /lib/libpcre.so.0 -> libpcre.so.0.0.1 -rwxr-xr-x root system_u:object_r:shlib_t /lib/libpcre.so.0.0.1
Im not sure that I get that :)
Just to get it working I did this on the other computer:
[root@flashdance ny]# setsebool -P httpd_disable_trans 1 [root@flashdance ny]# /etc/init.d/httpd restart Stopping httpd: [FAILED] Starting httpd: [ OK ]
Why doesnt httpd_disable_trans 0 work with apache on one computer?
On Wed, 2005-06-22 at 17:41 -0400, Jon August wrote:
I updated the policy after I found that there was a bug with starting DHCP and since then I haven't had any issues getting things to work. Things like a CGI script running sendmail to send an email - which used to show up in the audit log, now work fine.
What can I do to see if SELinux is still paying attention?
In addition to what others have said, /usr/sbin/sestatus is a tool for checking the status of SELinux. sestatus -v also provides further information based on the contents of /etc/sestatus.conf, so you can configure it to check the contexts of specific processes and program files. Might want to add httpd to that list. sestatus was contributed by the Hardened Gentoo folks, specifically Chris PeBenito.
BTW, I've noticed that FC4 systems seem to be losing the type on /etc/shadow, likely when firstboot creates the first user account. I then have to manually restorecon /etc/shadow, because the patched libraries and utilities are coded to just preserve whatever context is on the file when they update it, so if the context is ever wrong, it will remain wrong for subsequent updates. Possibly they should be using matchpathcon() instead.
selinux@lists.fedoraproject.org
-
Colin Walters -
Jon August -
Peter Magnusson -
Stephen Smalley