Andrej Presern wrote:
> Just some random thoughts/comments:
>
> * Linux does not have support for capabilities, it has support for
> capability lists (POSIX capabilities are really capability lists). These
> are two radically different paradigms and claiming that Linux has
> support for capabilities would be a misinformation to say the least (to
> put it bluntly: it would be either a lie or clear misunderstanding of
> concepts). Please do not confuse the two approaches, and please DO use
> the correct terms so that the approaches are not mixed if you don't want
> to create a bad image for Linux and its developers (as people read about
> capabilities and see Linux claiming to have support for them, they might
> think that Linux is more secure than it really is (or can be with
> capability lists), creating a false sense of security).
[Modern linguistic theories (according to my wife the linguistics
professor) accept the fact that language changes. The destinction is
that what "capability" meant yesterday to one group of people, is not
necessarily what it will mean tomorrow to others... If POSIX have
hijacked it to mean something other than what you want it to mean and
people start to use it that way, unfortunate as that is, you may just
have to live with it. Your distinction, however correct in some eyes,
is purely semantic and if you are not careful, stressing it will
conceal the significance of your important message.]
Just for reference, POSIX used to call these "capability lists"
privileges, but now they call them capabilities. Feel free to call
them whatever you want, but it will not change what they do.
The kernel provides a finite set of enhanced facilities over those
available to unprivileged users. Access to these privileges used to
be via the uid=0 user identity. The POSIX security model explicitly
tries to remove this relationship between identity and privilege. As
defined by POSIX, the capabilty model does this.. The linux kernel
currently implements half of the POSIX capability model. The
unimplemented half is having some mechanism to attribute file
capabilities with executable files.
I will inject my opinion about where to store the capabilities. I do
not feel it is appropriate to put the capabilities within a file.
There are a number of potential holes here, but my main objections are
that it makes the task of the administrator harder, and it offers very
limited support for old "legacy" applications. Ultimately, I would
like to see some filesystem support for capabilities to be stored as
file attributes. In the original linux-privs patches for 2.0.*, we
extended ext2 to have such support and it worked fine. I really can't
see what stops us from doing that for real... As Alan Cox has
indicated, having a mount mask for certain capabilities seems like a
very natural way of extending the current practice of suppressing
setuid binaries etc. with mount options.
The implementation of what Andrej prefers to call capabilities, has
not been ignored by the POSIX people. In point of fact it occupies a
reasonably large fraction of my copy of the POSIX.1e draft (#15). The
term that POSIX use to refer to it is "Manditory Access Control".
My reading of it, is that in addition to having MAC tokens (what
Andrej would call "capabilities") they have added a notion of
"dominance", where each MAC token is given a "level". In the model
Andrej discusses, two objects must share a MAC token to be able to
exchange information, the POSIX model includes the notion that there
can be a restriction on the direction of flow of information based on
which object has the dominating MAC token. (In general, it would
appear that information may only pass from a lower level to a higher
level.)
Whatever, the case, this is a part of POSIX.1e that is not currently
implemented in the Linux kernel.
> * You can't make a (good security) pie without breaking the (POSIX)
> eggs..
And you certainly cannot rule out POSIX based on a partial
implementation of the full model.
Best wishes
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu