lkml.org 
[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: caps in elf, next itteration (the hack get's bigger)
    Hello.

    On Tue, Apr 13, 1999 at 08:28:58AM +1000, Richard Gooch wrote:

    > This to me is one of the real blind-spots of some people who are
    > pushing capabilities. There is absolutely no need to remove the
    > privileges of the root account. By default root has all capabilities.
    >
    > Think about it: you will need *some* account* with the abilility to
    > grant caps anyway. So root is it.

    The way I see it, this needn't be the case. I believe what you are thinking
    is a chicken and egg trap - but, not as with chickens and eggs - it is easy
    to escape from without extensive biological study.

    When you initially set up a capabilities enabled system, you'll need some
    'root' account that would be able to set the CAP_SETFCAP capability.
    However, after a short while, you'll write a 'capabilities granter' - a
    program that, based on its own internal security checks (users, groups, time
    of day, mood of CPU), would grant capabilities to binaries. This program
    would have the CAP_SETFCAP bit (you would give it that using your root
    account), and as soon as this program is functional and correct, honoring
    capability setting requests properly, you can throw away the root
    account. You no longer have any use for it - it is just a security hazard,
    because it has total control.
    (Obviously, a Linux distribution would come preinstalled with capabilities).

    Now, I don't know how practical this is - but this is what a capabilities
    based systems seem to be all about. I think that it makes system
    administrating more complicated, because you can no longer use regular
    programs to control "the world" (you can't even use the 'chown' binary
    without making it capabilities aware, to change ownership of files root - or
    whatever your new administrator account is - don't own [Actually, you can,
    using the effective flag on the binary. But doing that for all executables
    that might be used by the administrator is foolish. Or maybe it isn't?]).

    This scheme moves administration from the hands of the kernel to the
    hands of user tools, in a way. Is this a good thing? I don't know.
    But I guess, and hope, the capabilities system in Linux would allow a user
    to choose between these two options (maybe with a boot-option) - with god,
    or without god... home users and non-paranoid admins would probably
    choose the former.

    Another approach might be to add a fourth set of process capabilities - a
    persistent set. This set would always be active, regardless of what is
    running. This would allow an administrator to run some utility that would
    grant him persistent capabilities - and from this point (in a subshell),
    this user would always be able to use his elevated capabilities without the
    need for capabilities aware processes. This breaks the standard, and is not
    terribly secure either, but it is a useful behavior.

    It is entirely possible that I messed up everything above, but this is what
    I think capabilities are.

    > The major practical benefit that capabilities provide is that you can
    > have privileged binaries that have *only* the privileges that they
    > need, and no more. Having a root account with full privileges is
    > completely orthogonal to this.

    Exactly. It is still a security risk.

    Nimrod

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