Re: RSBAC

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: RSBAC
Date: 02 Nov 1998 21:12:00 +0100

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

Hi Paul!

You wrote:

> > > The per-user stuff is indeed configurable.  As far as per-process goes,
> > > I would think that you could arrange some sort of MAC level "global"
> > > virtual /tmp directory so that processes would see both their own
> > > uid based /tmp and files from their particular MAC level, or some
> > > similar scheme?

> > That's an interesting idea to mix both worlds and let each module handle
> > specific parts, but - what do we do if dublicate names exist? I think,

> For duplicates, I'd think the rule would be to allow the per-user entry
> to exist as the default.  Perhaps though, it's better to have programs
> specificly go to /tmp/user or some such structure for purposeful file
> sharing, or to treat TEMPDIR as a global /tmp and /tmp as a per-user temp
> (or visa versa).

OK, we could provide an attribute tmpdir_behaviour for users and/or  
programs/processes with values like old_style/shared, user_based,  
process_based. Depending on that a lookup for /tmp would return different  
results. The default could be the old_style, so we do not run into  
incompatibility problems.

If program/process attribute is not old_style, it overrides the user  
setting. This lets us handle programs that depend on old_style.

> > we'd have to stick to a per-user basis, and a setuid just switches and
> > that's it.
> > All modules must work independently, nothing must interfere with another
> > module. Security levels are MAC only and switching the dir would change
> > too much for the other models.
> If we default to per-user and find the exceptions for per-machine, I
> think we can come up with a single solution.

A default value of user_based for the user attribute would still be OK for  
me, but all problematic programs must be identified and treated by the  
administrator, what might not be OK for some people.

> > P.S.: Would you mind moving this discussion to the RSBAC mailing list?
>
> I'd love to, but I was unable to subscribe from my home account :(  The
> name server seems strage, a direct lookup doesn't produce a result, but
> going to the authoritative nameserves and digging does.

Really strange. Morpork as a mailbox only has an MX entry, but that should  
not be a problem. You should be able to send a mail.

If you want, I can enter you manually (just mail me your address), but for  
posting you would need a relay account. I might create one at my business  
domain though.

Would it be OK to put a copy of our discussion into the list? I am sure  
other people are interested.

Amon.

--
## CrossPoint v3.11 ##
-
To unsubscribe ao@morpork.shnet.org (A. Ott) 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.