Messages in this thread | | | Date | Tue, 29 Feb 2000 09:09:17 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>: >Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said: > >[...] > >> I think the "forced" capabilities permit totally unprivileged users to >> accomplish something that does require privilege - such as changing a >> password. It doesn't grant the ability to change just any password; only >> the password of the user using the passwd utility, even then the user >> must provide the old password. Changing any password requires additional >> capabilities/role definition (such as security administrator - there may >> be several capabilities used to define the role of security admin). > >Please don't. That way you end up with thousands of capabilities, and the >whole mess becomes unmanageable. The way this should work, IMHO, is like >passwd(1) does today: It has the capability of changing any password, but >the _program_ restricts this to the individual user's password after extra >authentification. Sure, it is more orthogonal to use just one mechanism to >handle all security, but pragmatically it is probably better to design a >mix. The total complexity (kernel + userland) should be roughly the same >both ways (if there isn't an advantage due to better access to the >filesystem for userland), so that doesn't count as an argument.
Not thousands - there are only so many bits available. The limit is determined by implementation. 32, 64, 128?. I find using capabilities much simpler than having 10's-100's of programs that are setuid to root, and then attempt drop some privilege. THAT is unmanageable.
Using multiple passwords is the same problem - how many passwords do you have to know to implement a security administrator - one, five, 10... Now you also have the problem of keeping track of the passwords - another unmanageable task. My site has over 50 passwords that are necessary to implement system management. Do you really think anywone can keep track of these in memory? Much less - who has copies of them. It would be much simpler to eliminate the passwords, and use some form of capability list to assign roles to the administrators and operators.
------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- 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/
| |