From: Tom <tom@lemuria.org>
To: SE Linux <selinux@tycho.nsa.gov>
Subject: Re: policy question
Date: Thu, 18 Apr 2002 22:49:57 +0200 [thread overview]
Message-ID: <20020418224956.C11358@lemuria.org> (raw)
In-Reply-To: <20020418184739.17C063002C@lyta.coker.com.au>; from russell@coker.com.au on Thu, Apr 18, 2002 at 08:47:38PM +0200
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.
next prev parent reply other threads:[~2002-04-18 20:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 9:22 policy question Tom
2002-04-18 10:44 ` Russell Coker
2002-04-18 12:25 ` Tom
2002-04-18 14:51 ` Russell Coker
2002-04-18 15:15 ` Tom
2002-04-18 15:32 ` Stephen Smalley
2002-04-18 16:21 ` Tom
2002-04-18 18:28 ` Russell Coker
2002-04-18 20:40 ` Tom
2002-04-18 21:47 ` Russell Coker
2002-04-19 6:30 ` Tom
2002-04-18 16:08 ` Russell Coker
2002-04-18 16:32 ` Tom
2002-04-18 18:47 ` Russell Coker
2002-04-18 20:49 ` Tom [this message]
2002-04-18 21:44 ` Russell Coker
2002-04-19 6:14 ` Tom
2002-04-19 9:10 ` Russell Coker
2002-04-19 12:27 ` Tom
2002-04-19 15:02 ` Stephen Smalley
2002-04-18 15:22 ` Stephen Smalley
-- strict thread matches above, loose matches on Subject: below --
2002-05-02 10:11 Policy question Reino Wallin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020418224956.C11358@lemuria.org \
--to=tom@lemuria.org \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.