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
objects.
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
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu