lkml.org 
[lkml]   [1999]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectCapabilities done right...
Machek wrote:
> >
> > Next try with capabilities, this time against 2.3.1. Patch is
completely
> > safe and should significantly enhance system security. It is
completely
> > backward compatible: ie. no semantics change. Capabilities are
> > implemented using elf notes (and this version parses notes
correctly).
> > Software exists for adding capabilities at runtime, so you don't
even
> > 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
wonder
> 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,
etc).
They ALL provide filesystems that include the ability to store
privileges
(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"
privilege. This may seem like a catch-22 but its not.

>
> I suspect that it would be cleaner to have capabilities be a
name-space
> issue rather than an inode issue. For example, the one thing I've
always
> 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
the
process that is calling it has the "set capabilities on files"
capability,
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

--
John Wojtowicz, Secure Systems Engineer jwojtowicz@tcs-sec.com
Trusted Computer Solutions wojtowij@erols.com
Herndon, VA 20171




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

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2011 Jasper Spaans