[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2.1.97] more capabilities support
    Andrew Morgan wrote:
    > Andrej Presern writes:
    > > It is intresting what you say here. I have tried to explain a concept
    > > much securer than what is being presented here to some people, but have
    > > failed in doing so because of being unable to provide the complete
    > > implementation details due to my lack of Linux internals knowledge.
    > >
    > > If you are interested, I would very much like to explain it again to
    > > you.
    > I, for one, would like to read it.
    > > > The whole UNIX philosophy is to give the user a powerful tool. Yes, giving
    > > > people such a tool does imply that people can hurt themselves. But I'd
    > > > still prefer to be given the choice, instead of getting the "yes, dear,
    > > > these are the safe and approved interfaces, and if you don't like them,
    > > > tough, you're stuck with them" mentality.
    > >
    > > Don't give authority to people, give it to objects in the system. A
    > This is mostly a symantic distinction. "People" do not exist within a
    > computer (The movie TRON not withstanding :). Only their data (files)
    > and agents (applications) = "objects" as you call them.

    Then why associate the object named 'user id' with the authority? 'User
    id' could have bad intentions with the program that you designed, so why
    let him do that? Just don't give him the authority (ie the capability)
    to abuse your program for doing damage to the system and your user's

    Or why associate the authority to the program? The program could have
    been designed by a malicious author to steal your data and that wouldn't
    be that fortunate? The program can then be the one who can do damage to
    the user.

    Hmmm. That doesn't sound to good either.

    But what if we separated the authority from the identity of the object?
    Let the authority be the 'capability' (no, not like POSIX capability
    lists, I am talking about pure capabilities) that can be copied by any
    object, given to any object, taken from every object and reduced to a
    subset by any object, wouldn't that allow to set up an environment where
    both objects could coexist? This way various object don't need to trust
    each other, so you can setup a secure environment for mutually
    suspicious objects!

    > > separate authority from identity)
    > This is something that capabilities address very well.

    POSIX capabilities aka capability lists don't really do that. They are
    somewhat of a 'reverse mode' of ACLs - instead of objects, entities are
    associated with a list that defines what objects they can access. The
    problem with these is that an object can only carry one authority at a
    time - while it can do something it can't do something else. So you need
    more objects to accomodate all authority of the system, or you need to
    make a check (to make distinction), which authority the program should
    use. This way you make the program less efficient, because it needs to
    execute an additional 'if', thus becoming slower and more complex. It
    may seem as a small resource waste when the control is coarse grained,
    it will start to get bigger as the control will have to be more fine
    grained to accomodate security needs.

    You can compensate some of this 'cost' as the power of processors
    increases, but your performance and security of the system won't scale
    very well with the performance of the processor (you can see this
    phenomenon with Microsoft's products).

    People have written diploma thesys' that show that operating system
    kernels should only do resource multiplexing (which allows programs to
    implement self oriented powerfull algorhytms and thus be radically tuned
    while still leaving them the ability to choose a desired high level of
    abstraction), that small object spaces work faster (because it's
    cheaper to change an entry of the TLB than to flush and reload the whole
    TLB) and that tying the authority to an object is a no win situation
    (the object to which authority is tied is in better position to abuse
    its authority). I don't know why such ancient techniques like ACLs and
    POSIX lists are still being used at all - maybe it's because the last 20
    years we were living in Bill's wallet, or maybe it's because wrong kind
    of objects in the society were having too much authority, thus being
    able to abuse other objects. I really don't know.

    > > program should be able to do, so the program should only have as little
    > > authority as absolutely necessary to perform the action that a person
    > > designed it to do. Any more authority than that is a risk, because it
    > AKA, the "priniciple of minimal privilege" -- something that
    > capabilities take one very large step towards when compared with
    > setuid programs.

    How many different authorities are you going to store into the '6
    32bitbit spots' (as they have been described as the place where they
    could be held)? And how many checks are you going to have to do to
    assure that every possible authority has been handled that could
    potentially become a security hole? You wouldn't want to do them too
    much if you want to do something else in the program too, and possibly
    leave some space for other things on the disk too, such as data. But
    nevermind, we can wait for the next generation of processors that will
    be able to spend less time on security and do other stuff too. Why is
    DOS possibly still the best games performer? Because it gives the
    program the ability to do _anything_ (that is, because it spends less
    time on security).

    > > I hope any of what I stated above will at least be considered before
    > > concepts that have _proven_ to be wrong are implemented in the kernel.
    > > In the last 30 years, a lot was learned about information security. I
    > I'm happy to say that capabilities as a concept have emerged from this
    > research. It is my understanding that they are preferable to many of
    > the other alternatives because they can be implemented in such a way
    > that does not slow down the kernel.

    You don't know how right you are:) Only that I'm not talking about
    capability lists such as POSIX:)


    Andrej Presern,

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

     \ /
      Last update: 2005-03-22 13:42    [W:0.025 / U:12.876 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site