2

I'm trying to understand POSIX-capabilities principles, their transformation during execve() to be more specific. I'll put some quotes from documentation during my question:

       P'(ambient)     = (file is privileged) ? 0 : P(ambient)

       P'(permitted)   = (P(inheritable) & F(inheritable)) |
                         (F(permitted) & P(bounding)) | P'(ambient)

       P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)

       P'(inheritable) = P(inheritable)    [i.e., unchanged]

       P'(bounding)    = P(bounding)       [i.e., unchanged]

   where:

       P()   denotes the value of a thread capability set before the
             execve(2)

       P'()  denotes the value of a thread capability set after the
             execve(2)

       F()   denotes a file capability set

According to this, first of all we check, whether executable file is privileged or not. Privileged file is defined there as one that has capabilities or has the set-user-ID or set-group-ID bit enabled.

When determining the transformation of the ambient set during execve(2), 
a privileged file is one that has capabilities or 
has the set-user-ID or set-group-ID bit set.

Then we check, whether file's effective bit is enabled or not. So now we have 4 situations based on two checks:

  • Privileged file has effective bit enabled -> file has capabilities that has to be considered -> calculate new capabilities
  • Unprivileged file has effective bit disabled -> file has no capabilities -> use thread's ambient set
  • Privileged file has effective bit disabled -> file probably has setuid/setguid bit enabled. I assume, that means, that capabilities shouldn't be used at all not to mix two different permission tools -> thread's effective set becomes 0

I can't understand 4th case, though. Unprivileged file have effective bit enabled. It has no capabilities (since it's unprivileged), so

  1. How possibly can unprivileged file has effective bit enabled?
  2. Even if effective bit doesn't affect file's privilege status, what for should we set it enabled without permitted or effective capabilities?

So, my question is, what specific situation can possibly arise to lead to this 4th case?

1 Answer 1

1

I thought that this situation couldn’t arise, i.e. that the effective bit couldn’t be set if there is no permitted or inherited capability.

The behaviour seen with setcap appears to confirm this:

$ sudo setcap cap_chown=ep mybinary
$ getcap mybinary
mybinary = cap_chown+ep
$ sudo setcap cap_chown=e mybinary
$ getcap mybinary
mybinary =

However, as you discovered, it is possible to set the effective bit, even though no capabilities are stored:

$ xattr -l mybinary
0000   01 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00    ................
0010   00 00 00 00                                        ....

These values represent a vfs_cap_data structure, version 2 (0x02000001). The last bit set in the first 32-bit value indicates that these are effective capabilities; but the capabilities (inherited and permitted) are all set to 0.

5
  • I've faced this question once again and it seems to be a little confusing now. If we perform sudo setcap cap_chown=e mybinary from your example, than security.capability from xattr won't be empty: $ xattr -l mybinary security.capability: 0000 01 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 00 00 (I don't know how to format this properly). But if we remove all capabilities, than security.capability will be empty again. Does it mean setting effective bit without permitted or inherited is actually possible?
    – Ekaterina
    Mar 24, 2022 at 22:18
  • Wow, that’s interesting! I’ve updated the answer. Mar 25, 2022 at 9:46
  • Because there is only one effective bit for a file. Not one per capability. If the bit is set, then all permitted are copied to effective. May 7, 2022 at 22:04
  • @ctrl-alt-delor yes, that was never in doubt. What surprised me was that it’s possible to set the effective bit when the set of permitted capabilities is empty... May 8, 2022 at 5:39
  • The bit exists on the file-system, so the kernel needs a policy on what to do in this situation. Having the kernel block this configuration, would make it harder to test. However I would expect user mode programs to not do it (unless they are used for testing). May 8, 2022 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .