From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: dax@gurulabs.com, Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: linux-kernel@vger.kernel.org,
"michael@hostsharing.net" <michael@hostsharing.net>
Subject: Re: suid bit on directories
Date: Tue, 21 May 2002 08:34:08 -0500 (CDT) [thread overview]
Message-ID: <200205211334.IAA21528@tomcat.admin.navo.hpc.mil> (raw)
Dax Kelson <dax@gurulabs.com>:
>
> On Mon, 20 May 2002, Jesse Pollard wrote:
>
> > That is NOT wrong. The files belong to the server. Not a user. I've been
> > running a server that way for years.
>
> This is insecure.
>
> A user has a defined security context. If the user can create code that
> is then executed in a different security context (user httpd/nobody), then
> you've got a potential problem. If you have multiple users who can
> create code that executes in the *same* security context, you have a
> recipe for disaster.
correct.
> user1 can write a web app the delete/modifies the web app, or web app
> created files of user2.
Exactly what you get when the owner is hidden. Whose app got executed
that created/destroyed someone elses files? What files were created?
It all runs under the web server account... but the results are owned by
the attacked user so it looks like the user did it. Anything a CGI can
create, a CGI can execute or cause to be executed.
If you want a secured web server, DON'T let users create CGI. and don't
give the CGI the capability to execute other programs either. And this
is where compartmentalization comes into play.
All you know is that maybe the attack was via a web server. But you can't tell.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next reply other threads:[~2002-05-21 13:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 13:34 Jesse Pollard [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:34 Jesse Pollard
2002-05-18 8:34 Michael Hoennig
2002-05-18 8:52 ` Cedric Ware
2002-05-18 10:34 ` Michael Hoennig
2002-05-19 1:12 ` jw schultz
2002-05-20 13:04 ` Jesse Pollard
2002-05-20 13:24 ` Michael Hoennig
2002-05-20 14:03 ` Jesse Pollard
2002-05-20 14:53 ` Michael Hoennig
2002-05-20 18:12 ` dean gaudet
2002-05-21 17:48 ` Bill Davidsen
2002-05-20 19:28 ` Jesse Pollard
2002-05-20 20:58 ` Miquel van Smoorenburg
2002-05-20 21:15 ` Michael Hoennig
2002-05-21 18:03 ` Bill Davidsen
2002-05-22 4:44 ` Michael Hoennig
2002-05-21 3:49 ` Dax Kelson
2002-05-20 15:53 ` Bill Davidsen
2002-05-20 19:17 ` Albert D. Cahalan
2002-05-20 20:17 ` Jesse Pollard
2002-05-21 3:28 ` Dax Kelson
2002-05-21 3:58 ` Dax Kelson
2002-05-21 18:04 ` Bill Davidsen
2002-05-21 18:35 ` J Sloan
2002-05-20 15:42 ` Bill Davidsen
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=200205211334.IAA21528@tomcat.admin.navo.hpc.mil \
--to=pollard@tomcat.admin.navo.hpc.mil \
--cc=dax@gurulabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@hostsharing.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®