capabilities and privilege escalation

Kevin Day thekevinday at
Mon Aug 22 15:46:54 PDT 2011

On Sun, Aug 21, 2011 at 2:38 AM, Robert Connolly
<robert at> wrote:
> I found an interesting paper about Linux capabilities and privilege
> escalation:
> It explains how some capabilities can lead to a root shell. I commented out
> (removed) the capabilities for Shadow and Util-linux-ng because of a temp file
> race condition...
> Basically, umount, passwd, and other programs which create temporary files will
> create that file as the regular user (unless the program is suid), which allows
> the regular user to manipulate files such as /etc/mtab or /etc/shadow.
> For the moment suid-root is safer, but /bin/ping can keep using capabilities
> safely.
> robert

I find /etc/mtab to be of poor taste.
I have a bunch of patches that fix software to use /proc/mounts and
not /etc/mtab.
Thus leaving all of the mounted device listing to the kernel (who is
always correct).
Then there is no need to worry about clobbering /etc/mtab. (especially
if your on a read-only or limited-write system).

On page 2, the article mentions a stability problem when copying.
Their example is:
$ setcap cap_net_raw=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ cp /bin/png /tmp
$ getcap /tmp/png
No capabilities

I believe this behavior should be secure and that capabilities should
not be copyable by non-owners of the file.
Otherwise they could copy the binary and possibly alter the binary
without loosing the capabilities.
If they arent the owner, then they should not be able to write to the binary.

On page 4, the bypass capability limitations to me is not as sound.
Lets replace the words for capabilities with words about the password
for the root user.

"You may say << ok, but at least the root user requires a password >>.
Yes. But what is the point when the password can be guessed? A
successful guess could lead to data stealing, password forging, and
complete corruption of the system."

I don't believe in the statement:
  "Because some security system does not protect against ALL attack
vectors means we should not impose any security at all."

The real argument and the real problem in this case is that certain
applications need root access and the current design of the software
in question is at fault.

A better (but more troublesome for small projects like HLFS) solution
is to design the code to expose fewer risks. This can come at
performance and/or management cost, just like enterring a password
imposes a time delay of typing in the password, performing decryption,
data comparision, checksuming, etc...

In the case of /etc/shadow, this means that there should not be a
single file containing everybodies password.
Instead, a separate directory (example: /etc/shadow.d) should exist
with each person able to access the shadow file to their own
1) no root access needed to login or otherwise alter password
2) the user has control over their own password via a group or owner permission
The downsides are:
1) The program reading the password must then always sanitize the
read-in password data as it is now considerred unsafe input.
2) no software currently exists to read this (thus patching of
shadow-utils is required). While I will probably do this myself for my
system, I don't have the time right now nor do I see any reason for
you to do this just because I believe its the better alternative.
3) There may be a size/performance penalty of having multiple files.
4) It makes it easy for a user to mess themselves up.

On page 5, 6, and 7, many of those are attacks that exist independent
of posix cabilities. Thus they are really an independent problem and
require independent solutions, such as SSP.

The only notable part of this article is the section about "III. When
capability generates vulnerability".
These are real problems that should be addressed (which you seem to
already be doing, Robert).

All in all it is my understanding that capabilities should be used to
reduce the usage of setuid programs to reduce the amount of possible
damage exploits can do. This is different from outright stopping the

However, that race condition you mentioned sounds like a serious issue
with capabilities.

Kevin Day

More information about the hlfs-dev mailing list