On 03/10/2016 04:06 PM, Krzysztof Adamski wrote: > 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 :) Fair enough. The word "legacy" doesn't really convey anything helpful here, so I've removed it. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
