Re: RC separation of duty

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: RC separation of duty
Date: 09 Nov 1999 10:51:00 +0100

Next Article (by Subject): Removing CONFIG_RSBAC_SYNC_WRITE ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Re: RC separation of duty "Paul D. Robertson"
Top of Thread: RC separation of duty ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date] [Author] [Subject]

********* ***************** ********** ****  *****   ***** ************
  To subject Re: RC separation of duty
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

> On 8 Nov 1999, A. Ott wrote:
>
> > > For instance, SYSADMIN needs to log in via /usr/local/sbin/sshd,
> > > otherwise the maximum role privilege you can use is USER.  I don't mind
> > > having to fix sshd to do some sort of RSBAC call.
> >
> > No, this concept is not (yet) included in RC. You can only use AUTH model
> > to limit the list of users /bin/login may change to. This was my original
> > idea of login path limiting.
> >
> > Maybe I should allow a negative AUTH capability list, meaning 'every user
> > but the listed ones'. Or a range setting.
>
> Here's what I'm thinking of trying to accomplish:
>
> Let's say we have an ID called foo, and it's got the sysadmin role
> normally.  If foo logs in from the console, or SSH's in, I'd like it to
> be SYSADMIN, but if foo telnets in, I don't want the ID to be able to go
> higher than USER.  This gives me the ability to extend trust based on
> where an ID is coming from.  Eventually, I'd like to add source address
> or interfaces to the model.  eth0 could be my Internet interface and
> never get beyond USER, where eth1 could be my private network and have
> SYSADMIN and the console could have SECURITY OFFICER.

Sorry, but currently it is impossible to work with IP source addresses or  
net device names. This will change in the big socket object overhaul that  
is planned for some (near) future release. It will take some time until we  
are there.

> Maybe there's a better or more logical way to accomplish what I'd like to
> do.
>
> DG/UX B2 allowed MAC limits per IP/interface/program/ID...  So I could set
> the default MAC to an untrusted value, then any ID or process that wasn't
> spawned from a trusted network would never be able to break out of the
> MAC box.  You could compromise an admin ID and password, but if you
> weren't coming from a trusted location it didn't buy you anything.
> Likewise, compromising a daemon from an untrusted path still kept you at
> an untrusted level because the MAC set on the path couldn't dominate
> anything else on the box.

This is a good idea, but (s.a.) not yet possible here. See below for a  
different approach.

> Negative auth would be useful for setting daemons and users that aren't
> shell users out, but I'm not sure it gets me any closer to the above?
>
> Would a trusted /bin/rsbaclogin make sense at this point?  Maybe having
> something extensible that could set role and MAC attributes as a part of
> the TCB is the way to go.  Are RSBAC calls to do this available and
> easily used?

How about the following solution: Tell telnetd to use another login  
program which can only change to normal users (option -L here). If  
necessary, install several telnetd programs at different ports (via inetd  
etc.) and use Linux firewall to redirect access to those ports, based on  
source device/IP.

Mingetty always uses /bin/login, so this must be used for console logins.

sshd does its own setuid AFAIK, so give it another set of AUTH caps. As  
with telnet, you can also install several sshd programs and redirect using  
firewall rules.

Amon.

--
Please remove second ao for E-Mail reply - no spam please!
## CrossPoint v3.11 ##
-
To unsubscribe from the rsbac list, send a mail to
majordomo@morpork.shnet.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.