lkml.org 
[lkml]   [2000]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.069 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site