[rsbac] cron as non-root

[Amon Ott]

On Montag, 8. Dezember 2003 21:56, Arnout Engelen wrote:
> 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

Reading through it, I like your text a lot. Some suggestions:

- You write: "Adding the SETUID CAP to the Min Caps prevents it from being 
turned off, ever. (unless probably by setcap)" - You might add a hint that 
clearing the bit in Max Caps prevents SETUID CAP being set.

- setreuid is also restricted by RSBAC

- setuid sets all 4 uids

- seteuid(newid) is translated to setresuid(-1, newid, -1).

- In general: RSBAC intercepts any value setting of ruid, euid, fsuid (euid 
and fsuid optional), regardless of the system call used. If the value is the 
same as before, it is still checked. suid only has indirect right 
implications, so this one is not (yet) checked.

- If you enable Linux DAC checkings, behaviour _will_ be different. The suid 
bits still work, but all other changes (except saved uid) are controlled.
 
> 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.

It gives guarantees for the ruid only, which is used by RSBAC, and ignores the 
Linux model.
 
> 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).

Again: RSBAC protects itself in the first place, all Linux model effects are 
secondary.
 
> 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.

It is some more setup work, though. The new learning mode in 1.2.3-pre can 
reduce this work significantly.
 
> After all, it's better to be accidentally too restrictive than to be
> accidentally too permissive, imho :)

Right.

Good work!

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22