policy question

policy question

[Tom]

After the 3rd reading, I think I finally "got it" - the policy part,
that is. Objects, Domains, Types, Roles, you name it.

So, I'm now at the "learning by example" stage. I'm looking through the
example policy files, trying to understand what they do. I use that
apol tool to analyse it as well as looking through the raw files.


Now a question: One thing I'd like to write a policy about is a
seperated webserver. I *think* it can be done.

Scenario: Webhosting with PHP, multiple users (possibly many)
Danger: PHP runs as a module, i.e. with apache's user and permissions.
that means it is trivial for every user to acess other user's files,
including .php files that may include things like database passwords.

Solution: domain transition to individual user's domain when reading a
file of that user. something like
domain_auto_trans(httpd_t, user_webdata_t, user_t)
should do the trick (I say "something like" because this macro expands
to include only execution, but I see no reason why the same can't be
done for file open or read).

The tricky part is that the apache will have to revert BACK to its
original domain once the operation is done, i.e. something like "on
socket close, domain transition to httpd_t". however, the user_t domain
should not have the general ability to make a transition to httpd_t.

Am I making any sense? Or do I need to read the papers again? :)


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 11:22, Tom wrote:
> Scenario: Webhosting with PHP, multiple users (possibly many)
> Danger: PHP runs as a module, i.e. with apache's user and permissions.

Here's the problem, not just for SE Linux but also for regular Unix 
permissions models and every other security system I know of.

Trying to give access to only code from a certain shared object inside a 
program is never going to work.  Anything Apache can do to get access, some 
malicious code can also potentially do.

> Solution: domain transition to individual user's domain when reading a
> file of that user. something like
> domain_auto_trans(httpd_t, user_webdata_t, user_t)
> should do the trick (I say "something like" because this macro expands
> to include only execution, but I see no reason why the same can't be
> done for file open or read).

It could, but that't not the security model that the NSA people want.  It 
would just open too many security issues.

Even having a system call to allow a process to change domain (much less 
risky) is something that they don't want.

> The tricky part is that the apache will have to revert BACK to its
> original domain once the operation is done, i.e. something like "on
> socket close, domain transition to httpd_t". however, the user_t domain
> should not have the general ability to make a transition to httpd_t.
>
> Am I making any sense? Or do I need to read the papers again? :)

To do this type of thing you need to have the php code run from a separate 
program.  PHP has some support for this, but I could never get it to work 
properly.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 12:44:24PM +0200, Russell Coker wrote:
> > Scenario: Webhosting with PHP, multiple users (possibly many)
> > Danger: PHP runs as a module, i.e. with apache's user and permissions.
> 
> Here's the problem, not just for SE Linux but also for regular Unix 
> permissions models and every other security system I know of.

Absolutely. The problem is that you have a unified frontend with
diversification at the backend. This is the same issue you have for
ssh, except that ssh (and other remote login tools) have a method for
changing to a specific user, based on user/password data.


> Trying to give access to only code from a certain shared object inside a 
> program is never going to work.  Anything Apache can do to get access, some 
> malicious code can also potentially do.

That is not what I want to do. I want to regulate access to certain
FILES. I don't care about apache itself at this point. The scenario I
want to avoid is this:

/var/www/user1/script.php
/var/www/user2/script.php

where user2's script contains something like:
<? $f=fopen("../user1/script.php"); read($f); ?>




-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 14:25, Tom wrote:
> > > Scenario: Webhosting with PHP, multiple users (possibly many)
> > > Danger: PHP runs as a module, i.e. with apache's user and permissions.
> >
> > Here's the problem, not just for SE Linux but also for regular Unix
> > permissions models and every other security system I know of.
>
> Absolutely. The problem is that you have a unified frontend with
> diversification at the backend. This is the same issue you have for
> ssh, except that ssh (and other remote login tools) have a method for
> changing to a specific user, based on user/password data.

Ssh solves it by forking a new process and changing UID BEFORE doing any work.

> > Trying to give access to only code from a certain shared object inside a
> > program is never going to work.  Anything Apache can do to get access,
> > some malicious code can also potentially do.
>
> That is not what I want to do. I want to regulate access to certain
> FILES. I don't care about apache itself at this point. The scenario I
> want to avoid is this:
>
> /var/www/user1/script.php
> /var/www/user2/script.php
>
> where user2's script contains something like:
> <? $f=fopen("../user1/script.php"); read($f); ?>

What you could do is to have a unix domain socket named /var/www/socket/user1 
which the Apache process creates and then forks off a child process to run 
all PHP code for user1 under the UID of that user, and then pass back the 
data to Apache through the socket for retransmission to the client.

In concept this is reasonably simple, and the performance impact shouldn't be 
that great (a site with lots of static content and a small amount of PHP 
won't be hit much - a site with lots of PHP will take so much CPU time that 
it won't make much difference ;).

An Apache module should be able to handle this.


Also while we're talking about such things.  I think we need to split gpg 
into at least two parts.  We need a separate program to read the secret key 
file so it can trigger a domain_auto_trans rule and thus prevent a hostile 
script from doing "gpg -e ~/.gnupg/secring.gpg".

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 04:51:01PM +0200, Russell Coker wrote:
> > Absolutely. The problem is that you have a unified frontend with
> > diversification at the backend. This is the same issue you have for
> > ssh, except that ssh (and other remote login tools) have a method for
> > changing to a specific user, based on user/password data.
> 
> Ssh solves it by forking a new process and changing UID BEFORE doing any work.

Right. I want to do the same thing, but not with UIDs, but with
domains.


> > where user2's script contains something like:
> > <? $f=fopen("../user1/script.php"); read($f); ?>
> 
> What you could do is to have a unix domain socket named /var/www/socket/user1 
> which the Apache process creates and then forks off a child process to run 
> all PHP code for user1 under the UID of that user, and then pass back the 
> data to Apache through the socket for retransmission to the client.

That requires changes in the apache code, which is bug-prone and will
probably be lost with the next upgrade. I want to put the policy
enforcement into the kernel/security server, where it belongs.


In essence, it boils down to: "a script (php, cgi, whatever) that
belongs to user X can only access files of user X"

The sole problem being that the scripts aren't executed in the
unix-sense of execution, but by being loaded and interpreted by the
apache process.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Stephen Smalley]

On Thu, 18 Apr 2002, Tom wrote:

> The sole problem being that the scripts aren't executed in the
> unix-sense of execution, but by being loaded and interpreted by the
> apache process.

Immunix's SubDomain provides a mechanism for confining "subprocesses" for
web servers.  Read their paper for the details.

IMHO, if you truly want to confine these "scripts" differently than the
main apache process, they should run in separate processes.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com






--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 11:32:07AM -0400, Stephen Smalley wrote:
> Immunix's SubDomain provides a mechanism for confining "subprocesses" for
> web servers.  Read their paper for the details.
> 
> IMHO, if you truly want to confine these "scripts" differently than the
> main apache process, they should run in separate processes.

Of course. The real-life problem is that I would prefer to reach this
goal without major changes to apache or the environment. The regular
workings of apache don't allow for anything like this, if for no other
reason then the fact that the children "hang around" after they have
one request done to handle the next ones. Anything else and you drown
in fork() overhead.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 18:21, Tom wrote:
> On Thu, Apr 18, 2002 at 11:32:07AM -0400, Stephen Smalley wrote:
> > Immunix's SubDomain provides a mechanism for confining "subprocesses" for
> > web servers.  Read their paper for the details.
> >
> > IMHO, if you truly want to confine these "scripts" differently than the
> > main apache process, they should run in separate processes.
>
> Of course. The real-life problem is that I would prefer to reach this
> goal without major changes to apache or the environment. The regular
> workings of apache don't allow for anything like this, if for no other
> reason then the fact that the children "hang around" after they have
> one request done to handle the next ones. Anything else and you drown
> in fork() overhead.

That's easy to solve.  Such children hang around for a certain amount of time 
and then exit if they aren't being used.  Just like the model Apache uses for 
it's own processes.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 08:28:07PM +0200, Russell Coker wrote:
> > Of course. The real-life problem is that I would prefer to reach this
> > goal without major changes to apache or the environment. The regular
> > workings of apache don't allow for anything like this, if for no other
> > reason then the fact that the children "hang around" after they have
> > one request done to handle the next ones. Anything else and you drown
> > in fork() overhead.
> 
> That's easy to solve.  Such children hang around for a certain amount of time 
> and then exit if they aren't being used.  Just like the model Apache uses for 
> it's own processes.

I know all this. I've been a sysadmin for apache servers for a couple
of years.

The point is that the reuse of children makes the "fork and change UID"
approach impractical. It works for SSH, but not for apache.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 22:40, Tom wrote:
> On Thu, Apr 18, 2002 at 08:28:07PM +0200, Russell Coker wrote:
> > > Of course. The real-life problem is that I would prefer to reach this
> > > goal without major changes to apache or the environment. The regular
> > > workings of apache don't allow for anything like this, if for no other
> > > reason then the fact that the children "hang around" after they have
> > > one request done to handle the next ones. Anything else and you drown
> > > in fork() overhead.
> >
> > That's easy to solve.  Such children hang around for a certain amount of
> > time and then exit if they aren't being used.  Just like the model Apache
> > uses for it's own processes.
>
> I know all this. I've been a sysadmin for apache servers for a couple
> of years.
>
> The point is that the reuse of children makes the "fork and change UID"
> approach impractical. It works for SSH, but not for apache.

Sure it'll work for Apache!

On an active web server you don't have equal access to all domains, and each 
domain will have it's own load spikes.  So if you have co-processes staying 
around for 30 seconds after being used then you won't have too many running 
at once.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 11:47:02PM +0200, Russell Coker wrote:
> > The point is that the reuse of children makes the "fork and change UID"
> > approach impractical. It works for SSH, but not for apache.
> 
> Sure it'll work for Apache!
> 
> On an active web server you don't have equal access to all domains, and each 
> domain will have it's own load spikes.  So if you have co-processes staying 
> around for 30 seconds after being used then you won't have too many running 
> at once.

Sorry, but this is very much impractical in any real-life situation. 
First of all, it would require that apache keep track of which process has 
dropped to what UID and hands off incoming requests according to that table, 
which needs to get updated at each fork and each SIGCHLD.
Two, it also requires that apache handles load independently for each
UID, instead of globally for the whole server, including spare servers
to start or kill, request-handling and forking of new processes. In
short, a total rewrite of a critical component.
Three, on any mass-hosting server, it will drive memory requirements
through the roof within minutes. My company has webservers with
thousands of users. If just 10% of them get accessed at any given time, 
something a few search engine crawls can easily accomplish, we'll have 
several hundred apache instances hanging around, and that is without 
taking into account spare servers.
Four, you would have to fork() much more often than right now. The sole
reason for apache's spare server concept is that forking is so
expensive, so apache tries to avoid it at all costs. Anything that
introduces a considerable increase in forks can not be a good thing.


Which is why I'm trying to do what I need to do without any forks and
without digging deep into apache's heart. Our discussion gave me an
idea or two that I'll be testing. Thanks for the input.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 17:15, Tom wrote:
> On Thu, Apr 18, 2002 at 04:51:01PM +0200, Russell Coker wrote:
> > > Absolutely. The problem is that you have a unified frontend with
> > > diversification at the backend. This is the same issue you have for
> > > ssh, except that ssh (and other remote login tools) have a method for
> > > changing to a specific user, based on user/password data.
> >
> > Ssh solves it by forking a new process and changing UID BEFORE doing any
> > work.
>
> Right. I want to do the same thing, but not with UIDs, but with
> domains.

Changing UIDs involves much the same process as changing domains.

If you want to get any support from Apache people etc then it's best if you 
talk about changing UID (something that they all understand).

> > > where user2's script contains something like:
> > > <? $f=fopen("../user1/script.php"); read($f); ?>
> >
> > What you could do is to have a unix domain socket named
> > /var/www/socket/user1 which the Apache process creates and then forks off
> > a child process to run all PHP code for user1 under the UID of that user,
> > and then pass back the data to Apache through the socket for
> > retransmission to the client.
>
> That requires changes in the apache code, which is bug-prone and will

No changes should be needed to the Apache code, just to the module code.  Of 
course that's still a major PITA...

> In essence, it boils down to: "a script (php, cgi, whatever) that
> belongs to user X can only access files of user X"

Doing it for cgi is easy enough.  I could easily hack something up if the NSA 
people don't release the MITRE code.

> The sole problem being that the scripts aren't executed in the
> unix-sense of execution, but by being loaded and interpreted by the
> apache process.

Which means that they can't be given a different UID and therefore they can't 
be given a different domain because domain transition can only occur at exec 
time (just like for SUID programs).

The concept you have is wrong, nothing will make domain transitions on module 
load work.

PHP via CGI with suexec may work if your PHP requirements are small enough.  
Otherwise you need some module changes.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 06:08:28PM +0200, Russell Coker wrote:
> > In essence, it boils down to: "a script (php, cgi, whatever) that
> > belongs to user X can only access files of user X"
> 
> Doing it for cgi is easy enough.  I could easily hack something up if the NSA 
> people don't release the MITRE code.

I guess so. The cgi gets executed in a new process, at which time a
domain transition is trivial to set up. I guess I can do that myself as
a learning excercise.


> > The sole problem being that the scripts aren't executed in the
> > unix-sense of execution, but by being loaded and interpreted by the
> > apache process.
> 
> Which means that they can't be given a different UID and therefore they can't 
> be given a different domain because domain transition can only occur at exec 
> time (just like for SUID programs).

If that is so, then my question is answered. Is execution really the
only point for a domain transition? That would make sense, but I also
see reasons for doing transitions during other file access operations
(e.g. maybe you want to get a higher protection level while certain
files are open).


> The concept you have is wrong, nothing will make domain transitions on module 
> load work.

Not on module load. The PHP module is loaded when apache starts. I want
to make a domain transition when it accesses a file. Here's a simple
flowchart:


* HTTP request incoming
* Apache main process hands request to a child or forks a new one
* Child parses request, finds URL, does URL to filename translation
* Child opens file
==> domain transition
* File is found to be a php file and is handled by the PHP module
* PHP module opens files, reads, writes, whatever
* Output sent to client
* Socket close
==> transition back to original domain


I see that this may not be possible with the current SELinux code. I'm
trying to point out that it may be useful. PHP is not the only thing
coming to mind.


Maybe apache can initiate the domain transition itself? A singular
patch in the URL parsing instance ("read target file's domain and make a
transition to it") should be feasable. As you pointed out, this would
be similiar to what suexec does.


Again, it may still be that I have a gross misunderstanding of what is
possible and what not and how things work. If so, please point my
errors out.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 18:32, Tom wrote:
> > Which means that they can't be given a different UID and therefore they
> > can't be given a different domain because domain transition can only
> > occur at exec time (just like for SUID programs).
>
> If that is so, then my question is answered. Is execution really the
> only point for a domain transition?

Apparently, and the NSA people don't seem to like the idea of changing it.

> That would make sense, but I also
> see reasons for doing transitions during other file access operations
> (e.g. maybe you want to get a higher protection level while certain
> files are open).

Allowing domain transitions on the fly does not help much, if the process 
gets exploited then the attacker gets access to all domains.

> I see that this may not be possible with the current SELinux code. I'm
> trying to point out that it may be useful. PHP is not the only thing
> coming to mind.

Reducing security can always be "useful" by adding functionality...  ;)

> Maybe apache can initiate the domain transition itself? A singular
> patch in the URL parsing instance ("read target file's domain and make a
> transition to it") should be feasable. As you pointed out, this would
> be similiar to what suexec does.

No.  When you run suexec you can only do what it allows, suexec is designed 
to be small and well audited.  Apache is large and impossible to be audited.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 08:47:38PM +0200, Russell Coker wrote:
> > That would make sense, but I also
> > see reasons for doing transitions during other file access operations
> > (e.g. maybe you want to get a higher protection level while certain
> > files are open).
> 
> Allowing domain transitions on the fly does not help much, if the process 
> gets exploited then the attacker gets access to all domains.

You have me lost here. If I allow a specific, controlled domain
transition, how does that open up all domains to an attacker?


> > I see that this may not be possible with the current SELinux code. I'm
> > trying to point out that it may be useful. PHP is not the only thing
> > coming to mind.
> 
> Reducing security can always be "useful" by adding functionality...  ;)

I don't think that what essentially amounts to world-readability could
seriously be called security. A tighter handling of user files is
definitely good, if not necessary.

I have successfully attacked virtually all aspects of our companies
mass webhosting servers using nothing but a 10 line .php script. The
only thing between me and root was the fact that I didn't have the 
specific exploit for this specific platform. With better connections 
to the underground, I'd have scored yet another point at CTF.

None of which would have been possible if there had been a tight domain
for the PHP script to run in.


> > Maybe apache can initiate the domain transition itself? A singular
> > patch in the URL parsing instance ("read target file's domain and make a
> > transition to it") should be feasable. As you pointed out, this would
> > be similiar to what suexec does.
> 
> No.  When you run suexec you can only do what it allows, suexec is designed 
> to be small and well audited.  Apache is large and impossible to be audited.

Which is exactly why I don't want to mess with apache if it can be
avoided and instead put the access controls and enforcement into the
kernel.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Thu, 18 Apr 2002 22:49, Tom wrote:
> On Thu, Apr 18, 2002 at 08:47:38PM +0200, Russell Coker wrote:
> > > That would make sense, but I also
> > > see reasons for doing transitions during other file access operations
> > > (e.g. maybe you want to get a higher protection level while certain
> > > files are open).
> >
> > Allowing domain transitions on the fly does not help much, if the process
> > gets exploited then the attacker gets access to all domains.
>
> You have me lost here. If I allow a specific, controlled domain
> transition, how does that open up all domains to an attacker?

If we have 10 users with 10 different domains and allow Apache to change 
between them (forward and backward) at will, then anything which compromises 
Apache or any of it's scripts can get any of the domains.  In which case why 
not just save yourself the trouble and use a single domain.

> I have successfully attacked virtually all aspects of our companies
> mass webhosting servers using nothing but a 10 line .php script. The
> only thing between me and root was the fact that I didn't have the
> specific exploit for this specific platform. With better connections
> to the underground, I'd have scored yet another point at CTF.
>
> None of which would have been possible if there had been a tight domain
> for the PHP script to run in.

But a tight domain for PHP is impossible while PHP is essentially part of 
Apache.  To have a tight domain for PHP then you need to run it as a cgi-bin 
program using suexec.

> > > Maybe apache can initiate the domain transition itself? A singular
> > > patch in the URL parsing instance ("read target file's domain and make
> > > a transition to it") should be feasable. As you pointed out, this would
> > > be similiar to what suexec does.
> >
> > No.  When you run suexec you can only do what it allows, suexec is
> > designed to be small and well audited.  Apache is large and impossible to
> > be audited.
>
> Which is exactly why I don't want to mess with apache if it can be
> avoided and instead put the access controls and enforcement into the
> kernel.

The problem is that the kernel doesn't know what the application is trying to 
do with each file.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Thu, Apr 18, 2002 at 11:44:40PM +0200, Russell Coker wrote:
> > You have me lost here. If I allow a specific, controlled domain
> > transition, how does that open up all domains to an attacker?
> 
> If we have 10 users with 10 different domains and allow Apache to change 
> between them (forward and backward) at will, then anything which compromises 
> Apache or any of it's scripts can get any of the domains.  In which case why 
> not just save yourself the trouble and use a single domain.

I see two scenarios:

1) Apache itself is compromised. In that case, you are where you are
right now, namely that the attacker has all the rights that apache has.
Nothing gained, but nothing lost, either.

2) A single script gets compromised. In that case, the attacker is in a
tiny domain that allows access to only one user's files. That's a huge
gain, and this danger is many times higher than the other one.

There would be no transition between user domains. The transitions
allowed would be from apache to a user and from a user to apache. The
later would happen on exit. As long as your script is still doing
stuff, you are in the user domain.


> > None of which would have been possible if there had been a tight domain
> > for the PHP script to run in.
> 
> But a tight domain for PHP is impossible while PHP is essentially part of 
> Apache.  To have a tight domain for PHP then you need to run it as a cgi-bin 
> program using suexec.

All this was to find out whether it is possible with SELinux to have
the cake (module) and eat it, too (have security). Looks like it isn't.


> The problem is that the kernel doesn't know what the application is trying to 
> do with each file.

It doesn't have to. All it needs is to understand that it opens a file,
which it does understand pretty well, and that if that file has a
certain label, it needs to make a domain transition. That is apparently
the point it doesn't "get", so I'll have to look for a different way of
doing things.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Russell Coker]

On Fri, 19 Apr 2002 08:14, Tom wrote:
> > If we have 10 users with 10 different domains and allow Apache to change
> > between them (forward and backward) at will, then anything which
> > compromises Apache or any of it's scripts can get any of the domains.  In
> > which case why not just save yourself the trouble and use a single
> > domain.
>
> I see two scenarios:
>
> 1) Apache itself is compromised. In that case, you are where you are
> right now, namely that the attacker has all the rights that apache has.
> Nothing gained, but nothing lost, either.

With the suexec model someone who gains access to the Apache domain will not 
gain direct access to the user domains, they will only be able to transition 
to them through suexec and through the cgi-bin script.  Therefore even if the 
Apache domain is controlled by a hostile user they still will be limited as 
to what they can do to the user domain.

> 2) A single script gets compromised. In that case, the attacker is in a
> tiny domain that allows access to only one user's files. That's a huge
> gain, and this danger is many times higher than the other one.
>
> There would be no transition between user domains. The transitions
> allowed would be from apache to a user and from a user to apache.

Which also allows user -> apache -> other-user...

> The
> later would happen on exit. As long as your script is still doing
> stuff, you are in the user domain.

What do you mean by "exit"?  File close of script file?  That doesn't 
necessarily stop code running...

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Tom]

On Fri, Apr 19, 2002 at 11:10:03AM +0200, Russell Coker wrote:
> > 1) Apache itself is compromised. In that case, you are where you are
> > right now, namely that the attacker has all the rights that apache has.
> > Nothing gained, but nothing lost, either.
> 
> With the suexec model someone who gains access to the Apache domain will not 
> gain direct access to the user domains, they will only be able to transition 
> to them through suexec and through the cgi-bin script.  Therefore even if the 
> Apache domain is controlled by a hostile user they still will be limited as 
> to what they can do to the user domain.

Ok, that makes sense.


> > There would be no transition between user domains. The transitions
> > allowed would be from apache to a user and from a user to apache.
> 
> Which also allows user -> apache -> other-user...
> 
> > The
> > later would happen on exit. As long as your script is still doing
> > stuff, you are in the user domain.
> 
> What do you mean by "exit"?  File close of script file?  That doesn't 
> necessarily stop code running...

Two possibilities here. One being an active transition by apache
(requesting to enter a new domain) at the end of the PHP execution. The
other being a socket close. The later would mean the process remains in
the domain during keepalive. Apache doesn't tear the socket down while
code is still running, since there may still be output being added.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Stephen Smalley]

On Thu, 18 Apr 2002, Tom wrote:

> If that is so, then my question is answered. Is execution really the
> only point for a domain transition? That would make sense, but I also
> see reasons for doing transitions during other file access operations
> (e.g. maybe you want to get a higher protection level while certain
> files are open).

I answered the more general question (can a process change its own SID) in
the following message:
http://marc.theaimsgroup.com/?l=selinux&m=101343633303503&w=2

This is also discussed in the original design document, and is a criteria
for secure systems identified in the background documents (in particular,
the DTOS General System Security and Assurability Assessment Report,
available from
http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/technical-docs.html).

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com






--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy question

[Stephen Smalley]

On Thu, 18 Apr 2002, Tom wrote:

> Scenario: Webhosting with PHP, multiple users (possibly many)
> Danger: PHP runs as a module, i.e. with apache's user and permissions.
> that means it is trivial for every user to acess other user's files,
> including .php files that may include things like database passwords.

The example apache policy (by MITRE) provides separate domains for system
CGI scripts and user CGI scripts, and limits each to a particular set of
permissions.  MITRE also created a simple patch to suexec to transition to
a per-user security context in that case, using a revised apache policy
that allows for such transitions.  We haven't mainstreamed the modified
suexec or revised apache policy in the upstream distribution.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Policy question

[Reino Wallin]

I have defined a few nodes as well as a few interfaces in network.te,
and net_contexts.

In the te files for the standalone proxies (http and generic) the
following will do:

# Allow the domain to send to any node.
allow http_proxy_t node_type:node { tcp_send tcp_recv };

However, the same approach doesn't work in the inetd.te. Avc error
messages appears, and the following rules are supposed to be added.

# Allow the domain to send to any node.
allow inetd_t node_admin_t:node { tcp_send tcp_recv };
allow inetd_t node_dmz_t:node { tcp_send tcp_recv };
allow inetd_t node_vpn_t:node { tcp_send tcp_recv };
allow inetd_t node_internal_t:node { tcp_send tcp_recv };
allow inetd_t node_external_t:node { tcp_send tcp_recv };

If I add theese rules, then also the proxies that is executed from the
inetd works fine in enforcing mode.

Why are theese fine grained rules needed in the inetd.te but not in the
other te files?

Reino



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.