Re: [PATCH] execve.2: EPERM from filesystem capabilities.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 10, 2016 at 01:33:07AM +0100, Michael Kerrisk (man-pages) wrote:
Hello Krzysztof

On 03/09/2016 09:15 PM, Krzysztof Adamski wrote:
On Wed, Mar 09, 2016 at 01:49:41AM +0100, Michael Kerrisk (man-pages) wrote:
Hello Krzysztof

Sorry for the delayed follow up.

On 10/12/2015 09:45 PM, Krzysztof Adamski wrote:
An EPERM error can be returned when using filesystem capabilities and
capabilities to be added are not in permitted set.

This error return values was introduced by this patch:
5459c16 security: protect legacy applications from executing with
insufficient privilege

Can you explain in more detail the scenario where EPERM can be produced.
I can't see/produce it. Also, the code in the commit that you mention,
which was part of Linux 2.6.27, was thoroughly changed in Linux 2.6.29.

Hi Michael,
If you're interested in details, I explained it quite extensively here:
http://k.japko.eu/systemd-nspawn-ping-debug.html

The summary is that I used nspawn from systemd which drops some
capabilites (CAP_NET_ADMIN is amoung them) when spawning a container.
Now, since I used Fedora in container, my ping binary had filesystem
capabilites set:

# getcap /bin/ping
/bin/ping = cap_net_admin,cap_net_raw+ep

So when executing this application, kernel tried to give me
CAP_NET_ADMIN capabilities but they where not on permitted set so I've
got EPERM.

It was found in kernel 4.1 back then and I just retested this on kernel
4.3. Unfortunately I don't have time now to verify this for the latest
kernel but I would be surprised if this feature was removed.

Would you like me to extend/change the description in the patch somehow?

Okay -- I got it at last. I think the explanation requires quite
some detail. I added this to execve(2):

      EPERM  A  "capability-dumb"  applications  would not obtain the
             full set of permitted capabilities granted by  the  exe‐
             cutable file.  See capabilities(7).

And this to capabilities(7):

  Safety checking for capability-dumb binaries
      A  capability-dumb binary is a legacy application that has been
      marked to have file capabilities, but has not been converted to
      use  the  libcap(3)  API  to  manipulate its capabilities.  (In
      other words, this is  a  traditional  set-user-ID-root  program
      that has been switched to use file capabilities, but whose code
      has not been modified to understand  capabilities.)   For  such
      applications,  the effective capability bit is set on the file,
      so that  the  file  permitted  capabilities  are  automatically
      enabled  in  the process effective set when executing the file.
      The kernel recognizes a file which has the effective capability
      bit  set  as  capability-dumb  for  the  purpose  of  the check
      described here.

      When executing a capability-dumb binary, the kernel  checks  if
      the process obtained all permitted capabilities that were spec‐
      ified in the file permitted set, after the capability transfor‐
      mations described above have been performed.  (The typical rea‐
      son why this might not occur is that  the  capability  bounding
      set  masked  out some of the capabilities in the file permitted
      set.)  If the process did not obtain the full set of file  per‐
      mitted capabilities, then execve(2) fails with the error EPERM.
      This prevents possible security risks that could arise  when  a
      capability-dumb  application  is  executed  with less privilege
      that it needs.  Note that, by definition, the application could
      not itself recognize this problem, since it does not employ the
      libcap(3) API.

Let me know if you see anything amiss.

This looks good to me. It is however a little confusing (in Linux) to say that this is legacy mode since you could use libcap API long before filesystem capabilities were actually implemented in the kernel :)

Best regards,
Krzysztof Adamski
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux