diff options
author | Andrew G. Morgan <morgan@kernel.org> | 2008-07-23 21:28:24 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-07-24 10:47:22 -0700 |
commit | 5459c164f0591ee75ed0203bb8f3817f25948e2f (patch) | |
tree | 7b17a0cbadfc487d7311b7f5a41779ff33d6fe7f /kernel/capability.c | |
parent | 78ecba081224a2db5876b6b81cfed0b78f58adc7 (diff) | |
download | talos-obmc-linux-5459c164f0591ee75ed0203bb8f3817f25948e2f.tar.gz talos-obmc-linux-5459c164f0591ee75ed0203bb8f3817f25948e2f.zip |
security: protect legacy applications from executing with insufficient privilege
When cap_bset suppresses some of the forced (fP) capabilities of a file,
it is generally only safe to execute the program if it understands how to
recognize it doesn't have enough privilege to work correctly. For legacy
applications (fE!=0), which have no non-destructive way to determine that
they are missing privilege, we fail to execute (EPERM) any executable that
requires fP capabilities, but would otherwise get pP' < fP. This is a
fail-safe permission check.
For some discussion of why it is problematic for (legacy) privileged
applications to run with less than the set of capabilities requested for
them, see:
http://userweb.kernel.org/~morgan/sendmail-capabilities-war-story.html
With this iteration of this support, we do not include setuid-0 based
privilege protection from the bounding set. That is, the admin can still
(ab)use the bounding set to suppress the privileges of a setuid-0 program.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: cleanup]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/capability.c')
0 files changed, 0 insertions, 0 deletions