Re: understanding Su

From: Amon Ott <ao@rsbac.org>
Subject: Re: understanding Su
Date: Tue, 2 Jan 2001 11:51:01 +0100

Next Article (by Author): Bugfix #2 for 1.1.0 Amon Ott
Previous Article (by Author): rsbac-v1.1.1-pre6 kernel paging request Alessandro Iob
Next in Thread: Re: understanding Su "john huttley"
Articles sorted by: [Date] [Author] [Subject]

On Mon, 01 Jan 2001 john huttley wrote:
> I'm still trying to understand the implications of su.
> 
> root can su to any user without a password. This includes secoff -- which
> gives admin rights.
> 
> Thus root cannot be limited by secoff. Examples i've seen of making passwd
> readonly etc
> wont achieve anything because root can remove the security as easily as
> secoff installed it.
> 
> > > Does su have to be AUTH'd for setuid?
> >
> > Yes, of course. If not, root could work as any user, e.g. user secoff/400.
> > I do not trust root any further than I have to.
> 
> This seems to mean that su is not AUTH'd for setuid but is authed by
> capability
> for each UID individually.

Yes. The only program I sometimes keep with auth_may_setuid is /bin/login, all
others get the capability ranges they really need.

> How do you set up  su?

su usually gets capabilities for range 500:1000. If necessary, root is added to
allow users to become root via su. I never include secoff / uid 400.

To go on with su:
- /etc/sudoers should be write protected, e.g. with FF file flag read_only.
- You might use individual logging for READ-OPEN on /etc/sudoers or EXECUTE on
/bin/su
- the su binary should be write-protected, e.g. with FF flag execute_only
(might be inherited from /bin - everything in this dir should be execute_only
anyway).

Notes:
- If su has no secoff cap, no secoff problem.
- If /bin/su is tampered with, its cap set is reset on write-open.

> > > Programs such as  atd and crond drop privs on startup.
> > >
> > > It seems that they also want to re-acquire root privs to run scripts on
> > > behalf
> > > of users. Does this mean that they have to be AUTH'd for setuid?
> >
> > Yes. You sure want to control what user atd can execute commands for.
> 
> Considering this and su and ftpd and telnetd and ...., is there any way of
> using
> AUTH to allow them the capability of any UID >= 500 (example) without having
> to enumerate
> them??

It is called capability ranges. Just use auth_set_cap's second user param
last-user, e.g:

auth_set_cap FILE add /bin/su 500 100000

With rsbac_fd_menu, choose 'Auth Caps', add, enter values, and type 500:100000

If you want, you can also use -1 for 'highest possible'. Please note that RSBAC
uses unsigned 32 Bit uids, like 2.4.x kernels:

auth_set_cap FILE add /bin/su 500 -1

Again, in rsbac_fd_menu, type in 500:-1
The menu script will issue exactly the above command.

> Several daemons want to setuid to -2 (that very large number). Are there any
> implications
> in allowing them to do so?

This is the nobody account (65534 in kernels 2.2.x), which should always be
setup with minimum rights. Without RSBAC, all globally accessable files are
still unprotected. However, better nobody than root, right? So just let them.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.