Re: thoughts on kernel security issues

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 13 Jan 2005, Christoph Hellwig wrote:
>2B
> On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
> > Without that capability set, you can only execute binaries that you cannot
> > write to, and that you cannot _get_ write permission to (ie you can't be
> > the owner of them either - possibly only binaries where the owner is
> > root).
> 
> I think this is called "mount user-writeable filesystems with -noexec" ;-)

You miss the point.

It wouldn't be a global flag. It's a per-process flag. For example, many 
people _do_ need to execute binaries in their home directory. I do it all 
the time. I know what a compiler is.

Others do not necessarily do that. Sure, you could mount each users home 
directory separately with a bind mount, but that's not only inconvenient, 
it also misses the point - it's not about _where_ the binary is, it's 
about _who_ runs it.

What is the real issue with MS security? Is it that NT is findamentally a 
weak kernel? Hey, maybe. Or maybe not. More likely it's the mindset that 
you trust everything, regardless of where they are. Most users are admins, 
and you run any code you see (or don't see) by default, whether it's in an 
email attachement or whatever.

Containment is what real security is about. Everybody knows bugs happen, 
and that people do stupid things. Developers, users, whatever. We all do.

For example, in many environments it could possibly be a good idea to make
even _root_ have the "can run non-root binaries flag" clear by default. 
Imagine a system that booted up that way, and used PAM to enable non-root 
binaries on a per-user basis (for developers who need it or otherwise 
people who are trusted to have their own binaries). Think about what that 
means...

Every single deamon in the system would have the flag clear by default.  
You take over the web-server, and the most you have to play with are the
binaries that are already installed on the system (and the code you can
inject directly into the web server process from outside - that's likely
to be the _real_ security hazard).

It's just another easy containment. It's not real security in itself, but
_no_ single thing is "real security". You just add containment, to the
point where it gets increasingly difficult to get to some state where you
can do lots of damage (in a perfect world, exponentially more so, but
these containments are seldom independent or each other).

NOTE! I'd personally hate some of the security things. For example, I
think the "randomize code addresses" is absolutely horrible, just because
of the startup overhead it implies (specifically no pre-linking). I also
immensely dislike exec-shield because of the segment games it plays - I
think it makes sense in the short run but not in the long run, so I much
prefer that one as a "vendor feature", not as a "core feature". 

So when I talk about security, I have this double-standard where I end up 
convinced that many features are things that _I_ should not do, but 
others likely should ;)

		Linus