Re: suspected capabilities bug

From: Chris Evans (chris@ferret.lmh.ox.ac.uk)
Date: Tue Apr 11 2000 - 16:53:36 EST


On Tue, 11 Apr 2000, Eric Buddington wrote:

> I am running 2.2.14 with VLAN and IPsec patches.
>
> I have patched capability.h to give init cap_setpcap along with
> everything else, and modified fs/exec.c like this:

Your patch would appear to unconditionally give all exec()'ed processes
full privilege.

> + cap_set_full(bprm->cap_inheritable);
> + cap_set_full(bprm->cap_effective);

> My goal was to let non-root processes *begin* with particular
> capabilities by using a wrapper (e.g. sucap) to gain capabilities
> then execve() the desired program.

There have been problems in this area. The fix is in 2.3.99-pre3.
cap_setpcap is a bit of a kludge, the preferred way is to start off as
root and all caps, then prune caps to the set you want, then
prctl(PR_SET_KEEPCAPS, 1) <-- new, then setuid() away from root.

> On reboot, I found my user shell running with =eip , which
> kernel/sys.c:cap_emulate_setxuid() should prevent (when setiud()
> is called upon login)

Yes, the setuid() call will have cleared all capabilities when going from
uid 0 to uid != 0 (see above new prctl() call to prevent this). However,
your patch to exec will re-raise all capabilities when the shell is
execve()'d.

Cheers
Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST