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

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html