PHP and other CGI stuff

PHP and other CGI stuff

[Tom]

I think I need some conceptual help on PHP and other CGI matters (as we
know, PHP as a module doesn't give SELinux a chance at all).


I was planning to have really seperated domains for virtual hosting,
which means each PHP process should run in its own domain, e.g. dom1
for user 1, dom2 for user 2, etc.


How would I go about this? I've successfully added a new user (the
second_user comments are really helpful here), but I can't get the
domain macro set up correctly. This is probably caused by me being
unable to use suexec_domain($1), because this violates some assertions
for the sysadm_r and others.

I haven't found much documentation on the whole user management stuff,
but if I missed something, please point it out to me.


Also, if what I want is a dumb idea, please enlighten me. :)


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing 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: PHP and other CGI stuff

[Russell Coker]

On Mon, 20 Jan 2003 14:11, Tom wrote:
> I was planning to have really seperated domains for virtual hosting,
> which means each PHP process should run in its own domain, e.g. dom1
> for user 1, dom2 for user 2, etc.

I looked into that some time ago but discovered that PHP didn't work the same 
when invoked as an external process.  When run by the php-cgi method it would 
not correctly support IMP (the only PHP software I really care about).

Due to this I was unable to determine a better solution than to have a 
seperate instance of Apache for every separate PHP domain.  This consumes 
extra resources, but generally you don't have that many PHP customers...

> How would I go about this? I've successfully added a new user (the
> second_user comments are really helpful here), but I can't get the
> domain macro set up correctly. This is probably caused by me being
> unable to use suexec_domain($1), because this violates some assertions
> for the sysadm_r and others.

second_user is designed for someone who can login via ssh, read mail with 
mutt, etc.  For a different domain for web processes we need something a bit 
different.  Some of the various options have been discussed here over the 
last 18 months, but nothing has been done because the Apache policy basically 
works, and is complex enough that no-one really wants to do a serious 
re-write.

I think that the entire way that Apache operates should be reviewed in light 
of the way things are currently working in SE Linux policy and the usage of 
typical systems.  Many things have changed since the Apache policy was 
written, it's a bit of a dinosaur.

> I haven't found much documentation on the whole user management stuff,
> but if I missed something, please point it out to me.

Yes, we need some documentation on multiple user roles.  I briefly covered it 
in my tutorial at L-K, but we probably need something easier to understand 
than my L-K notes.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing 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: PHP and other CGI stuff

[Tom]

On Mon, Jan 20, 2003 at 03:05:47PM +0100, Russell Coker wrote:
> I looked into that some time ago but discovered that PHP didn't work the same 
> when invoked as an external process.  When run by the php-cgi method it would 
> not correctly support IMP (the only PHP software I really care about).

Hm, that's something I will have to investigate. But if it doesn't act
the same, I'd consider that a bug and report it to the PHP people.


> Due to this I was unable to determine a better solution than to have a 
> seperate instance of Apache for every separate PHP domain.  This consumes 
> extra resources, but generally you don't have that many PHP customers...

Well, we have about 1000. So running seperate Apaches is definitely not
an option.



> second_user is designed for someone who can login via ssh, read mail with 
> mutt, etc.  For a different domain for web processes we need something a bit 
> different.  Some of the various options have been discussed here over the 
> last 18 months, but nothing has been done because the Apache policy basically 
> works, and is complex enough that no-one really wants to do a serious 
> re-write.

Ok, then I'm starting one now. After some experimentation I think I've
found a way. But what is the performance impacts of domains and rules?

I would create 10 domains/types and about 700 rules per hosted site
(this is after macro expansion, of course).
What would the memory and performance impact of 10000 new types and 700000 
rules be? If it just means another 512 MB of memory for the machine, that's
not a problem.



> I think that the entire way that Apache operates should be reviewed in light 
> of the way things are currently working in SE Linux policy and the usage of 
> typical systems.  Many things have changed since the Apache policy was 
> written, it's a bit of a dinosaur.

I posted an updated one in october, though it retains much of the old
stuff, it should be much newer. See my other posting earlier today.


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing 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: PHP and other CGI stuff

[Russell Coker]

On Mon, 20 Jan 2003 16:25, Tom wrote:
> > Due to this I was unable to determine a better solution than to have a
> > seperate instance of Apache for every separate PHP domain.  This consumes
> > extra resources, but generally you don't have that many PHP customers...
>
> Well, we have about 1000. So running seperate Apaches is definitely not
> an option.

True.

> Ok, then I'm starting one now. After some experimentation I think I've
> found a way. But what is the performance impacts of domains and rules?

They take up non-pagable kernel memory, which reduces the performance of the 
machine.

> I would create 10 domains/types and about 700 rules per hosted site
> (this is after macro expansion, of course).
> What would the memory and performance impact of 10000 new types and 700000
> rules be? If it just means another 512 MB of memory for the machine, that's
> not a problem.

It sounds like you are multiplying the size of the policy-db by a factor of 
30.  If you have 30 times the RAM of the smaller SE Linux machines (given 
your comment about 512M it sounds like you do) then it should be OK.

There's no reason to expect this to give any problems apart from RAM usage and 
load time (both of which should scale linearly to the size of the policy).

Try it, if it fails then file some appropriate bug reports.

> > I think that the entire way that Apache operates should be reviewed in
> > light of the way things are currently working in SE Linux policy and the
> > usage of typical systems.  Many things have changed since the Apache
> > policy was written, it's a bit of a dinosaur.
>
> I posted an updated one in october, though it retains much of the old
> stuff, it should be much newer. See my other posting earlier today.

Which posting?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing 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.