12
root@macine:~# getcap ./some_bin
./some_bin =ep

What does "ep" mean? What are the capabilities of this binary?

muru
  • 69,900
  • 13
  • 192
  • 292
James
  • 131
  • 1
  • 1
  • 5
  • 4
    `capabilities(7)` have nothing to do with selinux. That file has **all** possible capabilities set. –  Apr 27 '19 at 16:36
  • https://vulp3cula.gitbook.io/hackers-grimoire/post-exploitation/privesc-linux#the-special-case-of-empty-capabilities – jesse_b Apr 27 '19 at 16:43
  • 1
    @Jesse_b that's wrong, there's no "special case" of empty capabilities. That guy was simply confused by the syntax. `setcap =ep file` will turn all capabilities **on**, `setcap = file` will turn them all off (make them empty) and `setcap -r file` will remove them completely. –  Apr 27 '19 at 20:41
  • @mosvy: Dew hwat? – jesse_b Apr 27 '19 at 20:58

2 Answers2

17
# getcap ./some_bin
./some_bin =ep

That binary has ALL the capabilites permitted (p) and effective (e) from the start.

In the textual representation of capabilities, a leading = is equivalent to all=. From the cap_to_text(3) manpage:

In the case that the leading operator is =, and no list of capabilities is provided, the action-list is assumed to refer to all capabilities. For example, the following three clauses are equivalent to each other (and indicate a completely empty capability set): all=; =; cap_chown,<every-other-capability>=.

Such a binary can do whatever it pleases, limited only by the capability bounding set, which on a typical desktop system includes everything (otherwise setuid binaries like su wouldn't work as expected).

Notice that this is just a "gotcha" of the textual representation used by libcap: in the security.capability extended attribute of the file for which getcap will print /file/path =ep, all the meaningful bits are effectively on; for an empty security.capability, /file/path = (with the = not followed by anything) will be printed instead.

If someone is still not convinced, here is a small experiment:

# cp /bin/ping /tmp/ping   # will wipe setuid bits and extented attributes
# su user -c '/tmp/ping localhost'
ping: socket: Operation not permitted
# setcap =ep /tmp/ping
# su user -c '/tmp/ping localhost'  # will work because of cap_net_raw
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.073 ms
^C
# setcap = /tmp/ping
# su user -c '/tmp/ping localhost'
ping: socket: Operation not permitted

Notice that an empty file capability is also different from a removed capability (capset -r /file/path), an empty file capability will block the Ambient set from being inherited when the file executes.

A subtlety of the =ep file capability is that if the bounding set is not a full one, then the kernel will prevent a program with =ep on it from executing (as described in the "Safety checking for capability-dumb binaries" section of the capabilities(7) manpage).

10

It is not a capability.

It means effective-set and permitted-set.

It means the capabilities will be put in the permitted set (p), and all permitted capabilities will be copied into the effective set (e).

The e is used for legacy programs (possibly most programs at the current time), that is programs that don't know about capabilities, so can not them-selves copy capabilities from permitted to effective.

As for why there is what looks like and empty set (as @mosvy has pointed out) the authors of the library have confused all with none (infinity and zero are two of the most confused numbers).

ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102