[rsbac] cron as non-root
ao at rsbac.org
Tue Dec 9 11:39:16 CET 2003
On Montag, 8. Dezember 2003 21:56, Arnout Engelen wrote:
> I think i mostly understand this now: wrote a summary on the wiki at
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
> 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
Again: RSBAC protects itself in the first place, all Linux model effects are
> 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 :)
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
More information about the rsbac