Re: RC separation of duty

From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: RC separation of duty
Date: Mon, 8 Nov 1999 08:52:04 -0500 (EST)

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

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.

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.  

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?

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."
                                                                     PSB#9280

-
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.