linux-kernel - Re: New Security Features, Please Comment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1228344292.6993.27.camel@lappy.spacevs.com>
Date:	Thu, 04 Dec 2008 09:44:52 +1100
From:	Geoffrey McRae <geoff@...idhost.com>
To:	Nick Andrew <nick@...k-andrew.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: New Security Features, Please Comment

On Wed, 2008-12-03 at 23:42 +1100, Nick Andrew wrote:
> On Wed, Dec 03, 2008 at 12:44:17PM +1100, Geoffrey McRae wrote:
> > On Wed, 2008-12-03 at 00:53 +0000, Alan Cox wrote:
> > > > (such as PHP) as the user that owns the website we are forced to fork a
> > > > new process per request, then call setuid/gid and then launch the script
> > > > language. This ofcource is resource intensive, but at present there is
> > > > no other solution.
> 
> [...]
> 
> > But once this set is introduced a HTTP server could be written that uses
> > forked children to handle requests, that have their identity swtiched
> > before doing any work, including parsing CGI scripts.
> 
> I think we can do that already, using FastCGI.
> 
> As I understand it, the traditional CGI server system call flow is:
> 
>    accept
>    fork
>     \ setuid(user)
>       exec(cgi script)
> 
> And I don't see how your 4 extra system calls would improve that flow.

The four extra calls would improve that flow like so...

enable_setpresuid
setuid

pre-fork child processes
\ setuid
  exec

accept request
choose free child
setpresuid(child, website user)
pass request to child

The children are pre-forked, so the overhead is in the setup... then
when the app recieves a request, it sets the child's uid to the uid of
the website, and then passes the request to the child, which, now, the
child is running as the website owner.

I know there are still loopholes in this methodology, like using the sig
handlers, but it is more secure then just doing nothing, there is no
fastCGI way to run each process as seperate users without the fork
overhead, which means every website can access every other websites data
without having to find any loop holes or write any special code.

It is more secure then just doing nothing.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/