CAPs

Ilmar S. Habibulin ilmar at ints.ru
Mon Nov 8 18:01:03 GMT 1999


On Fri, 5 Nov 1999, Andrew Morgan wrote:

> > There's no reason for login/su to have CAP_DAC_READ_SEARCH capability
> > when, from a policy standpoint, what it wants to do is set its capability
> > set to an arbitrary value according to what the user requests (and is
> > permitted). Giving it a capability just so it can retain or give up that
> > capability later is a mistake. The capabilities a process has should
> > closely mirror the activities required of it.
> 
> I guess I'm being dense, perhaps I don't understand what's been said. I
> thought you said that you can get by with only giving login
> [IRIX_]CAP_SETPCAP. If an attacker can overcome login in some way, how
> is having control of [IRIX_]CAP_SETPCAP different from the attacker
> having control of CAP_*?
I think that here we have the same problem that the suid programms have.
So how do the developers of POSIX suppose to use this capability scheme
(without extended capabilities like SETPCAP)?
As i understand init(1) should carry all permited set with inheritence. It
will pass it to getty and login. And what should we do with su,
telnet(login with the inheritence from the inetd)? I do not understand. :(
Who should i( or who should) set the permited and inherited sets of
capabilities and when?
 

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message



More information about the posix1e mailing list