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

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

Nice to hear that someone does not think my concept is completly
idiodic. I think the main issue here is that everyone is assuming that
this is only for use with CGI scripts, which could be abused, but as
Mike has mentioned, this is not the only use case. I am sure that with
some hacking and idea bouncing, this problem can be solved, and solved
in a very neat and clean way.

My concept is just that, a concept, build on it, expand it, fill the
gaps, and it will eventually become a working concept worth implementing
(I hope), dont just shoot it to hell.

The setuid/gid concept in linux is very limited, it would be nice to be
able to grant programs limited use of setuid, and even go one step
further, grant programs limited ability to set child uids.

To be completly honest, this is the kind of functionallity I expected to
already be there, and I was hopeing someone would tell me to RTFM on
function X that already does this...

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