Messages in this thread | | | Date | Sun, 28 Jun 1998 00:13:47 -0700 | From | Andrew Morgan <> | Subject | Re: Secure-linux and standard kernel |
| |
Hi,
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
| |