[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.027 / U:21.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site