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]
Date:	Thu, 04 Dec 2008 00:39:23 +0100
From:	Miquel van Smoorenburg <miquels@...tron.nl>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Geoffrey McRae <geoff@...idhost.com>,
	Nick Andrew <nick@...k-andrew.net>,
	linux-kernel@...r.kernel.org
Subject: Re: New Security Features, Please Comment

On Wed, 2008-12-03 at 23:08 +0000, Alan Cox wrote:
> > 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.
> 
> But the child process may already have been trojanned by a previous user
> so it gains you nothing.
> 
> > It is more secure then just doing nothing.
> 
> I'm not convinced. Not remotely.

Well, in this particular case, and with this API, perhaps not.

But there really is something to be said for being able to limit the
setuid range of a process.

Right now, applications that want to switch to several different
UIDs/GIDs must be setuid root themself or at least have the right
capability. But once an app has that it can switch to any uid, including
root or other system users.

It would be great if you could say 'limit setuid() to saved-uid + uids
1000-2000' or something like that.

If then the userlevel NFS server gets owned you can at least be sure
none of the files in /bin have been modified ..

Note that there are patches on the net for linux, freebsd and probably
other OSes that do exactly this, so there definately is a need.

It could even be used to give normal users a range of uids to use for
sandboxes. Just an idea, I haven't really thought that through.

Mike.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ