[rsbac] cron as non-root

[Arnout Engelen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, 

I think i mostly understand this now: wrote a summary on the wiki at
http://zhware.ath.cx/cgi-bin/oswiki.cgi/RsbacAndSuid?action=show

The bottom line is that, when DAC ownership in the RSBAC kernel config
is set to 'off', the AUTH module does not give any guarantees for
processes that have CAP_SETUID set in their Min Caps list. 

This means there are (rare) cases where a program is ran by a mortal
user, has CAP_SETUID in its Min Caps list, has AUTH set to, for example,
only '8', however can *still* gain effective uid 0 (even though some 
people (like me ;)) might at first expect AUTH to prevent that from 
happening).

I'd recommend people to turn on CONFIG_RSBAC_DAC_OWNER and 
CONFIG_RSBAC_AUTH_DAC_OWNER in the RSBAC kernel config. Even though only
little is gained (RSBAC itself bases its decisions on the ruid which isn't 
affected, so only rare (but tricky) cases as above are prevented), also 
nothing is lost.  

After all, it's better to be accidentally too restrictive than to be
accidentally too permissive, imho :)


Arnout

On Mon, Dec 08, 2003 at 03:59:29PM +0100, Amon Ott wrote:
> 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?

forgot to mention that: indeed.
  
> > 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.

that indeed seems to be that case :) - totally correct, but it sure took
me by surprise.

- -- 
Arnout Engelen <arnoutbac at bzzt.net>

  "If it sounds good, it /is/ good."
          -- Duke Ellington
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/1OVtWSAvNcFEP+sRAlI7AJ9O5xj1rv9EyshDlmK/4DxuTeQiVACfVSI6
/Xx1Mh/aWixRh5ui80aPmEk=
=P5mS
-----END PGP SIGNATURE-----