[lkml]   [1999]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectCapabilities done right...
Machek wrote:
> >
> > Next try with capabilities, this time against 2.3.1. Patch is
> > safe and should significantly enhance system security. It is
> > backward compatible: ie. no semantics change. Capabilities are
> > implemented using elf notes (and this version parses notes
> > Software exists for adding capabilities at runtime, so you don't
> > require a recompile.
> I'm not entirely convinced. The thing with ELF notes is that they only

> work with ELF. That may sound obvious, and it is, but it makes me
> whether it's the right way at all.

Thats what I've said all along. Not to mention that the
ELF header capabilities idea is probably insecure from the start. One
wouldn't place the permission bits inside the file, ehh? So why should
we place the capabilities, inside the file. For one thing, unless
you really do some weird (and IMHO kludge) stuff, anyone who has
the ability to modify the contents of the file also has the ability
to modify the capabilities. I don't think that the kernel can
truly "trust" that the ELF headers haven't been modified in a
illegitimate manner. Even if you do put other checks in (i.e.
checking for setuid bit before applying file capabilities
to the process, etc.), but thats another story.

I deal with several OS'es that provide "principle of least privilege"
support. Most notably Trusted Solaris, and SecureWare (HP, Digital,
They ALL provide filesystems that include the ability to store
(read capabilities).

They also give you (at least) three privilege sets per process.
Permitted, inheritable, and effective. These seem to be there
in the linux kernel. As well, they allow you to set two privilege sets
on each regular file. Allowed, and forced sets (but there appears to
be only one in the linux kernel). To set a privilege
on a file, the process that is doing so must have the "file set
privilege. This may seem like a catch-22 but its not.

> I suspect that it would be cleaner to have capabilities be a
> issue rather than an inode issue. For example, the one thing I've
> wanted to do with symlinks is to have symlinks that can change the
> privileges of the lookup - it's complex and maybe not a good idea, but

> it's a more intriguing concept and works with shellscripts and other
> systems where you can't add ELF notes..

A system call should be the only way to change the files capability
sets (forced and allowed), and that system call should check to see if
process that is calling it has the "set capabilities on files"
in its effective capabilities set. Inode or namespace is fine and
dandy with me, as long as they don't get put into the CONTENTS
of the file ;-).

Thanks for your time Linus,


John Wojtowicz, Secure Systems Engineer
Trusted Computer Solutions
Herndon, VA 20171

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.028 / U:1.932 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site