Messages in this thread | | | Date | Tue, 13 Apr 1999 23:04:36 +0300 | From | Nimrod Zimerman <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Hello.
On Tue, Apr 13, 1999 at 08:28:58AM +1000, Richard Gooch wrote:
> This to me is one of the real blind-spots of some people who are > pushing capabilities. There is absolutely no need to remove the > privileges of the root account. By default root has all capabilities. > > Think about it: you will need *some* account* with the abilility to > grant caps anyway. So root is it.
The way I see it, this needn't be the case. I believe what you are thinking is a chicken and egg trap - but, not as with chickens and eggs - it is easy to escape from without extensive biological study.
When you initially set up a capabilities enabled system, you'll need some 'root' account that would be able to set the CAP_SETFCAP capability. However, after a short while, you'll write a 'capabilities granter' - a program that, based on its own internal security checks (users, groups, time of day, mood of CPU), would grant capabilities to binaries. This program would have the CAP_SETFCAP bit (you would give it that using your root account), and as soon as this program is functional and correct, honoring capability setting requests properly, you can throw away the root account. You no longer have any use for it - it is just a security hazard, because it has total control. (Obviously, a Linux distribution would come preinstalled with capabilities).
Now, I don't know how practical this is - but this is what a capabilities based systems seem to be all about. I think that it makes system administrating more complicated, because you can no longer use regular programs to control "the world" (you can't even use the 'chown' binary without making it capabilities aware, to change ownership of files root - or whatever your new administrator account is - don't own [Actually, you can, using the effective flag on the binary. But doing that for all executables that might be used by the administrator is foolish. Or maybe it isn't?]).
This scheme moves administration from the hands of the kernel to the hands of user tools, in a way. Is this a good thing? I don't know. But I guess, and hope, the capabilities system in Linux would allow a user to choose between these two options (maybe with a boot-option) - with god, or without god... home users and non-paranoid admins would probably choose the former.
Another approach might be to add a fourth set of process capabilities - a persistent set. This set would always be active, regardless of what is running. This would allow an administrator to run some utility that would grant him persistent capabilities - and from this point (in a subshell), this user would always be able to use his elevated capabilities without the need for capabilities aware processes. This breaks the standard, and is not terribly secure either, but it is a useful behavior.
It is entirely possible that I messed up everything above, but this is what I think capabilities are.
> The major practical benefit that capabilities provide is that you can > have privileged binaries that have *only* the privileges that they > need, and no more. Having a root account with full privileges is > completely orthogonal to this.
Exactly. It is still a security risk.
Nimrod
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |