execve.2: EPERM from filesystem capabilities.
PATCH 1/1 execve.2: EPERM from filesystem capabilities.
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
---
man2/execve.2 | 4 ++++
1 file changed, 4 insertions(+)
man2/execve.2 +0 -0
@@ -465,6 +465,10 @@ and the file has the set-user-ID or set-group-ID bit set.
The process is being traced, the user is not the superuser and the file has the set-user-ID or set-group-ID bit set.
.TP
+.BR EPERM " (since Linux 2.6.27)"
+The file has filesystem capabilities defined that are not on a permitted set of +capabilities of the process.
+.TP
.B ETXTBSY
Executable was open for writing by one or more processes.
.SH CONFORMING TO
Signature · 6 lines
2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hello Krzysztof
Sorry for the delayed follow up.
Quoted 6 lines · Krzysztof Adamski
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.
Cheers,
Michael
Quoted 21 lines
Signed-off-by Krzysztof Adamski <[email protected]>--- man2/execve.2 | 4 ++++ 1 file changed, 4 insertions(+)man2/execve.2 +4
-0@@ -465,6 +465,10 @@ and the file has the set-user-ID or set-group-ID bit set. The process is being traced, the user is not the superuser and the file has the set-user-ID or set-group-ID bit set. .TP +.BR EPERM " (since Linux 2.6.27)" +The file has filesystem capabilities defined that are not on a permitted set of +capabilities of the process. +.TP .B ETXTBSY Executable was open for writing by one or more processes. .SH CONFORMING TO
Signature · 7 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Sorry for the delayed follow up.
Quoted 3 lines · Krzysztof Adamski
An EPERM error can be returned when using filesystem capabilities and capabilities to be added are not in permitted set.
Quoted 7 lines
Quoted 3 lines
This error return values was introduced by this patch:
5459c16 security: protect legacy applications from executing with insufficient privilegeCan 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?
Best regards,
Krzysztof Adamski
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hello Krzysztof
Quoted 33 lines · Krzysztof Adamski
Quoted 8 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Sorry for the delayed follow up.
Quoted 3 lines · Krzysztof Adamski
An EPERM error can be returned when using filesystem capabilities and capabilities to be added are not in permitted set.
Quoted 7 lines
Quoted 3 lines
This error return values was introduced by this patch:
5459c16 security: protect legacy applications from executing with insufficient privilegeCan 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.htmlThe summary is that I used nspawn from systemd which drops some capabilites (
CAP_NET_ADMINis 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+epSo when executing this application, kernel tried to give me
CAP_NET_ADMINcapabilities but they where not on permitted set so I've got EPERM.
Quoted 5 lines
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.
Thanks,
Michael
Signature · 7 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 79 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Quoted 33 lines · Krzysztof Adamski
Quoted 8 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Sorry for the delayed follow up.
Quoted 3 lines · Krzysztof Adamski
An EPERM error can be returned when using filesystem capabilities and capabilities to be added are not in permitted set.
Quoted 7 lines
Quoted 3 lines
This error return values was introduced by this patch:
5459c16 security: protect legacy applications from executing with insufficient privilegeCan 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.htmlThe summary is that I used nspawn from systemd which drops some capabilites (
CAP_NET_ADMINis 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+epSo when executing this application, kernel tried to give me
CAP_NET_ADMINcapabilities but they where not on permitted set so I've got EPERM.Quoted 5 lines
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.
Quoted 1 line
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 80 lines · Krzysztof Adamski
Quoted 79 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Quoted 33 lines · Krzysztof Adamski
Quoted 8 lines · Michael Kerrisk (man-pages)
Hello Krzysztof
Sorry for the delayed follow up.
Quoted 3 lines · Krzysztof Adamski
An EPERM error can be returned when using filesystem capabilities and capabilities to be added are not in permitted set.
Quoted 7 lines
Quoted 3 lines
This error return values was introduced by this patch:
5459c16 security: protect legacy applications from executing with insufficient privilegeCan 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.htmlThe summary is that I used nspawn from systemd which drops some capabilites (
CAP_NET_ADMINis 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+epSo when executing this application, kernel tried to give me
CAP_NET_ADMINcapabilities but they where not on permitted set so I've got EPERM.Quoted 5 lines
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.
Quoted 5 lines
Quoted 1 line
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
Signature · 7 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Michael Kerrisk (man-pages)
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).
this sounds wrong for multiple reasons:
- "A applications" doesn't make sense ... making "application" singular seems to be the most logical step
- it should be "could not obtain" instead of "would not obtain"
- the cap part sounds confusing/misleading to me -- filesystem based caps can modify the effective, inheritable, or permitted set
- calling them "capability-dumb" is prejudicial ... see below
how about:
An application with capabilities attached via the filesystem was unable to update the capability sets. See capabilities(7).
Quoted 15 lines
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.
this text makes it sound like using filesystem caps is always wrong when in reality it's quite a desirable feature. let's look at ping since that is what spawned this thread.
historically, the only way to make ping usable by non-root users was to make it setuid. this left admins with an ugly choice: non-root users didn't get ping access, or they had to mark a networking binary setuid. historically admins/distros just made it setuid.
the ping authors tried to make this less of a security issue by adding logic to drop root during most of its execution and only grab it again when trying to create the raw socket. but still, the program could be abused because it's setuid.
libcap comes into play as a way to more selectively drop caps *that it already has*. even if ping is linked against libcap and makes calls to it, it still must be granted the caps in the first place. which means the program continues to be marked setuid, and there's still code that can be abused (even if we manage to close the window a little bit).
with the introduction of filesystem caps, we now have an even better
option: the program is *not* marked setuid, but we do grant it the few caps it needs to run. so even from the very first insn executed, the kernel has guaranteed that all the other unrelated caps are dropped.
libcap is still orthogonal here: it's a method to manage caps you have and could still be used to drop things once it's got the raw socket, but it also still does not help for non-root users.
there is a side story specific to ping with later kernels wrt the new IPPROTO_ICMP socket type, but that only worked for ICMP & IPv4. it would be a few more years before IPv6 support was added. it also had to be setup first with specific group ranges which made it a pita.
calling an application that uses filesystem capabilities "dumb" is like calling every application that is marked setuid "dumb". it just doesn't make sense.
-mike