[rsbac] cron as non-root
ao at rsbac.org
Mon Dec 8 15:59:29 CET 2003
On Montag, 8. Dezember 2003 11:44, Arnout Engelen wrote:
> i'm still fiddling a bit with rsbac, and as excercise, i'm trying to
> restrict the running services as much as possible. I ran into a strange
> problem with cron.
> cron was running as root, and allowed an AUTH 8 to change to the 'mail'
> user. I changed its ownership to 'nobody:daemon', turned on setuid/setgid
> bits and made /var/run writable for the daemon group, and added SETUID
> and SETGID CAPs.
> Now this seemed to work, until i did my 'ps u --user root' and saw cron
> running as root. This is strange because it doesn't have an AUTH 0.
The setuid/setgid bits only change the Linux effective user and group, so the
real user is still root (or whoever started the program).
> I copied the cron executable to my homedir, chowned it to my user
> account and removed the setuid bit. Still, when I run it (under the user
> account), it mysteriously becomes root.
This is the first thing that looks strange to me. Does this copy of cron also
have SETUID cap set?
> Attached is a strace. (i gave strace AUTH 8 and CAP SETUID SETGID flags)
Looking at the strace:
setresuid32(0xffffffff, 0, 0xffffffff) = 0
sets the effective uid to 0, which is not controlled by RSBAC in default
kernel config. After this call, you are back to root rights in Linux model,
although not in RSBAC.
I would be interested to see what happens when DAC ownership has been enabled
in RSBAC kernel config, both in "Other options" and AUTH. The setresuid32
call should be properly intercepted.
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
More information about the rsbac