CAPs

[Andrew Morgan]

James Buster wrote:
> 
> On Nov 5,  2:15pm, Andrew Morgan wrote:
> } Linux's CAP_SETPCAP will go away when there is real filesystem support
> } for capabilities.
> 
> Why? Being able to change your capability set in violation of security
> policy has nothing to do with the filesystem.

My impression from the draft is that filesystem capabilities are there
to represent the administrator's security policy for the system. As an
admin, I'd like to be able to know the security limitations on a closed
source binary like login.

> } IRIX's CAP_SETPCAP seems less of a problem - at least
> } you can audit which processes can benefit from it!
> 
> Audit wouldn't be a problem for Linux, either. I'm not sure what
> you mean here.

The POSIX drafts are pretty clear that one of the problems capabilities
are supposed to address is the problem of unchecked inheritence of
'superuser' privilege. In a traditional UNIX framework, you get root and
your done - every program you subsequently invoke, everything you choose
to do can be done with full superuser privilege.

The full model requires that for a process to obtain permitted
capabilities, it must have been prepared for them. Namely, its file
attributes associated with capabilities must allow the program to
enable/inherit capabilities. From an auditing/verification perspective,
this is a really powerful concept. In the limit, if there are no
capabilities set on any file accessible to a system, there is no way a
process can become privileged. Similarly, if you use 'find' to identify
all of the programs that have capabilities raised in their file
attributes, you have made a list of all of the capability senstive
programs on the system - a finite number of things to audit.

Things like Linux's CAP_SETPCAP shatter this simple property. Any
process with CAP_SETPCAP can give CAP_SETPCAP to any other process. So,
let's say there are three processes A, B and C. Each possessing one
distinct permitted capability, and each program susceptible to some form
of attack. A's permitted capability is CAP_SETPCAP. An attacker
overwhelms A, B and C. It instructs A to raise CAP_SETPCAP in B's
process. B then has two raised capabilities. B is then instructed to
raise both of its capabilities in the process C. C now has three raised
capabilities. Finally, the attacker compiles evil.c and instructs C to
raise all three of these capabilities in the running evil program. Not
only does this mean the admin was never able to audit a program that
obtained a capability, but he's also not in a position to limit the
number of capabilities that the attacker was able to raise in one
process.

> } How does it differ in reality from raising all forced capabilities for
> } the login/su programs?
> 
> 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_*?

Thanks

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