Date: Sun, 24 Oct 2004 18:45:26 +0200
From: Nico -telmich- Schottelius <nico-linux-owl@...ottelius.org>
To: owl-users@...ts.openwall.com
Subject: Re: sudo: why not?

Solar Designer [Sat, Oct 23, 2004 at 05:30:04PM +0400]:
> > I just wanted to point to rsbac, as it at least removes the possibility
> > for most users to setuid() and that way to 'exploit' su.
> 
> I really do not see how RSBAC is of any help here.  You grant group
> privileges for su just to those who are supposed to use su (if at all),
> whether or not you use RSBAC on the system (for other great purposes).

That's not exaclty what happens when using RSBAC.

I'll try to explain how rsbac works and where I see the differences:

- su is mode 4755 (or 4750, doesn't really matter for this example)

1. rsbac kernel boots
2. user 'test' logs in
3. user 'test' tries to use 'su' or any other program, which is setuid
-> user fails, because the rsbac kernel denies any setuid() by default

4. rsbac_officer logs in and gives user 'test' the permissions to use
   'su' to setuid to a specific id
5. user 'test' can setuid() to this/the user rsbac_officer allows him to

The difference betwenn normal and rsbac systems:

- normal kernel doesn't check for setuid()s
- normally only su itself checks for a correct password, it does not
  check whether the user is allowed to start su
- normally su allows _anybody_ to change to _anybody else's_ id, rsbac
  only allows predefined changes

I hope I made it clear where I see the difference.

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux