Using dyntransition to reduce privileges for Web application

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2011 08:45 PM, Scott Gifford wrote:
> Hello,
> 
> 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?  That
> would help me ensure that this domain could only make things more secure,
> not less.
> 
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 interacting with
> 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,c43
s0:c2,c43

Is fine.

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 similar
> applications, your thoughts are appreciated.
> 
> Thanks!
> 
> -----Scott.
> 
> 
> 
> 
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk00nFUACgkQrlYvE4MpobOKJwCfRu8tS7Xy4x8HGVpWY5bNSvoj
+VMAn1vpid4ccpHISQgk18jhBmp+dzMe
=zdTS
-----END PGP SIGNATURE-----