-----BEGIN PGP SIGNED MESSAGE-----
On 01/15/2011 08:45 PM, Scott Gifford wrote:
I'm experimenting with SELinux policies again. I've got a test server set
up now, so I have a bit more freedom and flexibility. I have a policy that
is basically working, and wanted to get some feedback on it.
I'm working on designing a security architecture for a Web application we
have under development, and creating an SELinux policy to help implement it.
I would like to prevent any flaws in Apache or the Web application from
leaking access to other HTTP worker processes for current or future
connections, where credentials of other users may be accessible.
The Web server begins in the httpd_t domain, which has somewhat more
privileges than our application needs. For example it has access to the
listening HTTP socket, where it could accept new connections and so access
future connections. I would like to reduce the privileges of the HTTP
worker processes after the connection is accepted but before any user data
has been processed or our application code has been executed.
I have this working with some mod_perl code which hooks into Apache right
after it accepts the connection, and changes its running domain to
httpd_portal_app_t. I did this by allowing a dyntransition from httpd_t to
httpd_portal_app_t, then writing the new context to "/proc/$$/attr/current",
and verified it is working with ps -Z. That domain has a smaller set of
privileges than httpd_t, and is not allowed to do things like accept new
connections, listen on new sockets, read from log files, etc. There is no
rule allowing httpd_portal_app_t to transition back to httpd_t, and after
handling a single connection, the process exits (it is configured with the
Apache option MaxRequestsPerChild 1).
I am still testing and prototyping, but so far this is all working. I have
a few questions, though.
First, I see a lot of warnings in "SELinux by example" and other places on
the Web about how using dyntransition is a bad idea. Is that true in this
case, and if so is there a better way to get a similar degree of isolation
without taking the performance hit that a CGI-based environment would cost?
It is a
matter of the http_portal_app_t might be able to influence
httpd_t through some back channel that SELinux does not block.
Basically the books and literature is saying setexeccon/fork/exec is
more secure then fork/setexec.
Second, in RHEL 5, is there a way to constrain my httpd_portal_app_t to have
its permission set bounded by that of httpd_t? That is, so
that httpd_portal_app_t cannot have any privileges that httpd_t does not
have? I see that some versions of SELinux are able to enforce this with the
"typebounds" command, but that doesn't seem to be available in RHEL 5?
would help me ensure that this domain could only make things more secure,
No. The stuff you are reading about is not available as far as I know.
Third, since my main goal here is to prevent processes from
each other inappropriately, I would like to prevent each HTTP worker from
reading any information from "/proc" for other HTTP workers. Currently they
are allowed to do this, because they all run in the same domain. Is there
any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab
random MCS labels to separate the processes. I would suggest using two
Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need
the processes to handle data it might get a little more complicated.
Finally, if anybody has any thoughts or suggestions from doing
applications, your thoughts are appreciated.
selinux mailing list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----