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.
> With respect to capabilities, I don't ever want to see patches that don't
> have the whole picture. And quite frankly, going by past experience, the
> POSIX committee has never had a big picture in their life (which is ok:
> the POSIX standard wasn't about "getting the big picture", it was
> expressly about very small pictures indeed. But it does imply that POSIX
> is not a good guide to kernel internals).
>
> Also Morgan, you mentioned that you want to get rid of the capability to
> set capabilities because you worry that it is a security risk. Sorry, but
> that's the kind of prison mentality that I refuse to have in the kernel.
> In my very strong opinion, the kernel should _allow_ things, and never
> restrict things.
The model that I tried to present does not even have a notion of
denying, it only has a notion of allowing. That is, there are no "you
can't do that" responses (because that itself is a leak of information -
the program can try different privileged operations to determine the
power that it has, which is a bad thing if, for example, the program was
modified by the attacker and the attacker does not know the actual
authority of the program).
> As such, we should _allow_ the capability to raise other capabilities. If
> you don't like that capability, you can just make sure that it is cleared
> at boot for everybody, and then nobody can inherit it and nobody can ever
> get it any other way either (as nobody has the capability to raise the
> capability).
>
> 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
person doesn't have to be able to perform an action on /etc/passwd, a
system object does! (ie it's not really the person who accesses a file,
the program is, so you should control the program, not the person ->
separate authority from identity)
Also, programs should not be able to hurt other objects without explicit
permission to do that. The person who makes the program decides what the
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
can be abused by people who want the program to also do things that the
program _wasn't_ designed to do (ie, a weapon is a tool with superfluous
power that can be abused to hurt people).
It's never the interface that is the main issue because it can be made
one way or another. It's the concept that is behind the interface that
matters.
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
hope its time that some of that knowledge is actually used in mainstream
operating systems.
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