Bug 646472

Where are the docs on how to use %caps in spec files?

Panu does such a document exist?

Not really, other than rpm 4.7.0 release notes which says:
It's now possible to specify file capabilities in %files section of spec files using %caps(<capabilities>) attribute. <capabilities> is simply the textual representation of capabilities as specified in the draft. 

And that's pretty much all there is to say about it, as rpm does no processing of its own on the capability string, ie its the same format as setcap(8) accepts.

It might have been nice to come up with some good docs before throwing bugs at us, no?  What "draft" is referred to there, Panu?

I've read a bunch of man pages, and am trying to understand how this will work.  It looks like capability of

   cap_setuid,cap_setuid+pe

will do the expected thing for suexec, but it is pretty complicated following through the rules.  Particularly we need to be sure that the process which suexec itself execve's will not be executing with the SETUID/SETGID capabilities.  (at least, in the "effective" set, I think).  

Q: Does it matter much if a less-privileged app executes with the SETUID capability set in "permitted" but not "effective"?

Possibly suexec should either be clearing its capability sets (or merely its bounding set?), or possibly checking the capability sets of file it execves.

The rule for execve in capabilities(7):

           P’(permitted) = (P(inheritable) & F(inheritable)) |
                           (F(permitted) & cap_bset)

surprised me.  What is the point of the "inheritable" capset if it is binary ORed with the permitted capset in the file, rather than a binary AND?  (i.e. the inheritable capset does not impose an limit on what capabilities can be inherited, only the bounding set does that)

1) What is the "capability bounding set" going to be in the httpd parent?  It looks like this is up to userspace/init (and hence up to Fedora policy?).

2) Similarly, can the httpd parent expect to be executed with all three capsets (permitted, inheritable, effective) set to all-1s?

It would be nice/necessary to get these things documented so admins can understand what is going on as well as humble packagers.

It might have been nice to come up with some good docs before throwing bugs at us, no?  What "draft" is referred to there, Panu?

I've read a bunch of man pages, and am trying to understand how this will work.  It looks like capability of

   cap_setuid,cap_setuid+pe

will do the expected thing for suexec, but it is pretty complicated following through the rules.  Particularly we need to be sure that the process which suexec itself execve's will not be executing with the SETUID/SETGID capabilities.  (at least, in the "effective" set, I think).  

Q: Does it matter much if a less-privileged app executes with the SETUID capability set in "permitted" but not "effective"?

Possibly suexec should either be clearing its capability sets (or merely its bounding set?), or possibly checking the capability sets of file it execves.

The rule for execve in capabilities(7):

           P’(permitted) = (P(inheritable) & F(inheritable)) |
                           (F(permitted) & cap_bset)

surprised me.  What is the point of the "inheritable" capset if it is binary ORed with the permitted capset in the file, rather than a binary AND?  (i.e. the inheritable capset does not impose an limit on what capabilities can be inherited, only the bounding set does that)

1) What is the "capability bounding set" going to be in the httpd parent?  It looks like this is up to userspace/init (and hence up to Fedora policy?).

2) Similarly, can the httpd parent expect to be executed with all three capsets (permitted, inheritable, effective) set to all-1s?

It would be nice/necessary to get these things documented so admins can understand what is going on as well as humble packagers.

I meant a capability of:

   cap_setuid,cap_setgid+pe

there, and sorry for the double-post.

Well one of the reasons for opening this feature is to collect information on what we are missing.

Steve Grubb would be the best source of info on your question.  Steve?

I think you should be dropping your capabilities after you change your uid/gid, whether or not you are using setuid or file cababilities in normal course, although people might code up suexec in such a way that they expect full capability access when running the command.

SELinux policy only has 

allow httpd_suexec_t self:capability { setuid setgid };

Which means we have not witnessed the need for additional capabilities.

Joe, You can make suexev run captest to see what capabilities the child process gets. The Bounding set is the new inheritance flags in 2.6.26 and later kernels. 

You need to have permitted == effective. There was a misguided notion that permitted would be all the capabilities that a process can have and the effective be the ones in effect. The process could swing in capabilities as needed so that its least privileged. However, an attack can do that too, so its useless to not have permitted == effective.

Just set the file based capabilities as you mentioned and try running captest. I think you'll see that everything works out OK. If captest has any capabilities listed, let us know what it reports.

https://koji.fedoraproject.org/koji/buildinfo?buildID=205712