statd: drop all capabilities from the bounding set as well
authorJeff Layton <jlayton@redhat.com>
Tue, 29 May 2012 18:23:18 +0000 (14:23 -0400)
committerSteve Dickson <steved@redhat.com>
Tue, 29 May 2012 18:44:17 +0000 (14:44 -0400)
commit1ca82a963ace17397bd7ec09f5e0707badd7c254
tree35a5320e575c087a63908357af4df66f4e2812c4
parentddb095f82becc94c8e3a2429cc755dee5d1808c9
statd: drop all capabilities from the bounding set as well

statd drops all capabilities except for CAP_NET_BIND when it starts.
It's possible though that if it ever had a compromise that an attacker would
be able to invoke a setuid process (or something with file capabilities) in
order to reinstate some caps.

This could happen as a result of the daemon becoming compromised, or
possibly as a result of the ha-callout program becoming compromised.

In order to prevent that, have statd also prune the capability bounding
set to nothing prior to dropping capabilities. That ensures that the
process won't be able to reacquire capabilities via any means --
including exec'ing a setuid program.

We do however need to be cognizant of the fact that PR_CAPBSET_DROP was
only added in 2.6.25, so check to make sure that #define exists via
autoconf before we rely on it. In order to do that, we must add
ax_check_define.m4 from the GNU autoconf macro archive.

Furthermore, do a runtime check to see if /proc/sys/kernel/cap-bound
exists before attempting to clear the bounding set. If it does, then
don't bother trying since it won't work. In that event though, do
throw a warning however since the presence of that file indicates that
there is a disconnect between the build and runtime environments.

Acked-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
support/nsm/file.c