setcap/getcap limitations

Mon Sep 4 12:08:42 UTC 2017

On 2017-08-31 10:56, Serge E. Hallyn wrote:
> Quoting Richard Guy Briggs (rgb at redhat.com):
> > On 2017-05-11 22:37, Serge E. Hallyn wrote:
> > > Quoting Richard Guy Briggs (rgb at redhat.com):
> > > > Capabilities gurus,
> > > 
> > > I cc:d Andrew as he maintains the source package,
> > > 
> > > > These may arguably be useless or meaningless combinations, but I found them
> > > > sufficiently puzzling as to need to document and report the behaviour.  They
> > > > appear to be leftovers from a time when fE may have been a bitfield rather than
> > > > a boolean.
> > > > 
> > > > 
> > > > 1 - BUG: setcap manpage refers to non-existant cap_from_text(3) and cap_set_file(3)
> > > > manpages (fedora).  (It turns out it is in libcap-devel which makes
> > > > sense, but isn't very useful for users of setcap/getcap(8) rather than
> > > > developers.)
> > > 
> > > Hm, yeah, I suppose.  In the libcap source though they all come
> > > together.  Perhaps this is cause for distro bugs to make a
> > > common libcap-doc package which both libcap-devel and libcap2-bin
> > > depend on?  Really not sure of the best solution.
> > 
> > I agree it sounds like a distro-level issue, thanks.
> > 
> > > > 2 - BUG: setcap requires dummy capability present to set or clear effective bit
> > > 
> > > Getting ready for a short road trip, will look at the rest this weekend.
> > 
> > Any further thoughts on the three below?
> 
> Sorry!  Yes, responses inline below.
> 
> > > > While attempting to issue the setcap command to set or clear the effective bit,
> > > > the latter of which is a boolean rather than a capability set, a fatal error
> > > > was returned with a usage message that didn't make much sense:
> > > > 	# setcap +e /tmp/test
> > > > 	fatal error: Invalid argument
> > > > 	usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ]
> > > >  	Note <filename> must be a regular (non-symlink) file.
> > > > So in order to set it, I need to use a dummy capability, such as:
> > > > 	# setcap cap_sys_admin+e /tmp/test
> 
> This I think is a bug that should be fixed in setcap.  Like you say, just
> setcap -e /tmp/test should work.

Ok, bug 1...

> > > > 3- BUG: getcap doesn't show effective bit set if no other fP or fI bits are set
> > > > 
> > > > 	# setcap cap_sys_admin+pe /tmp/test
> > > > 	# getcap /tmp/test
> > > > 	/tmp/test = cap_sys_admin+ep
> > > > 	# getfattr --absolute-names --e hex -n security.capability /tmp/test
> > > > 	security.capability=0x0100000200002000000000000000000000000000
> > > > 	# setfattr -n security.capability -v 0x0100000200000000000000000000000000000000 /tmp/test
> > > > 	# getcap /tmp/test 
> > > > 	/tmp/test =
> > > > 	# getfattr --absolute-names --e hex -n security.capability /tmp/test
> > > > 	security.capability=0x0100000200000000000000000000000000000000
> > > > 	# setcap cap_sys_admin-p /tmp/test
> > > > 	# getfattr --absolute-names --e hex -n security.capability /tmp/test
> > > > 	# file: /tmp/test
> > > > 	security.capability=0x0000000200000000000000000000000000000000
> > > > So, getcap lies, where getfattr is more honest but awkward.
> 
> Yeah I'd call this a bug too.  In practice, from the kernel's point of
> view, it's true there is no effective bit set that requires a p or i, but
> this can lead to a dangerous situation where a a tool now only added cap_net_admin
> to the permitted set, but the kernel recognized it as effective.

Bug 2...

> > > > Q: How do I set one fP capability and a different fI capability?
> 
> > > > >From looking at the manpage for cap_from_text, it appears that capability sets
> > > > can be specified in a similar manner to chmod(1), using "=", "+" and "-"
> > > > operators, but pracitical poking doesn't seem to work that way.  "+" seems to
> > > > work like "=" and "-" seems to clear all except the version field.
> > > > Other than resorting to setfattr, how can I set something like
> > > > cap_sys_admin+p with cap_audit_read,cap_audit_write,cap_audit_control+i ?
> 
> The manpage points to you to cap_from_text which gives you an example - you
> put it in quotes :)
> 
> ubuntu at oci:~$ sudo setcap "cap_sys_admin+p cap_net_admin+i" capsh
> ubuntu at oci:~$ getfattr --absolute-names --e hex -n security.capability capsh
> # file: capsh
> security.capability=0x0000000200002000001000000000000000000000

Oops, ok, fair enough.

> > > > 4 - BUG: The capabilities version doesn't get cleared when all cap bits are
> > > > cleared.  This fools kernel into thinking there are fcaps set.
> > > > 
> > > > As can be seen above, if setcap is used with "<capability>-<p|e|i>" to unset
> > > > capabilities then the version field is leftover, set.  Arguably the -r option
> > > > should have been used to remove the attribute entirely, but in this case, the
> > > > kernel assumes that capabilities are in use due to a valid version number
> > > > present (VFS_CAP_REVISION_MASK).  This could be solved in the kernel by
> > > > clearing that attribute field entirely if there are no values set other than
> > > > the version number, or by having "has_cap" check for a value more than just the
> > > > version number.  Is it possible to remove some capabilities from a file but not
> > > > all?  Or is it intended to simply specify the new set of capabilities that are
> > > > to be set and ignore or strip away the unwanted ones from the set?
> 
> Yeah I'm gonna gree this seems like a bug which could have subtle consequences.

Bug 3...

> Do you have time to address these?  If not, I may find time later in the year,
> but not right now.  So I'm wondering how we should track these, since there is
> no issue tracker at https://git.kernel.org/pub/scm/linux/kernel/git/morgan/libcap.git/
> If I'm not stepping on toes, I could create a copy of the kernel.org tree at github
> to track issues and pull requests...  But I'm pretty sure I'd be stepping on toes.

If it were kernel work, I could probably fit it in, but userspace stuff
is going to need more ramp up with the specific packages involved which
is harder to know when I can slot that in.

Tracking it would be helpful.  How much work would it be to convince
Andrew to enable a bugtracker on that git repo?  I'd offer to enter them
in the audit userspace git repo bugtracker, but that would
pollute/dillute it.

> -serge

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html