Re: Implementation questions

From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: Implementation questions
Date: Tue, 19 Jan 1999 12:06:06 -0500 (EST)

Next Article (by Date): Re: Implementation questions ao@morpork.shnet.org (A. Ott)
Previous Article (by Date): Error in 1.0.7a for alpha ao@morpork.shnet.org (A. Ott)
Top of Thread: Implementation questions "Paul D. Robertson"
Next in Thread: Re: Implementation questions ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date] [Author] [Subject]

On 14 Jan 1999, A. Ott wrote:

> > I'm looking to bring this port up soon.
> 
> Good. There are other bug fixes in there, too. And the new (but  
> independent) secure delete (overwrite) feature.

I've created my RSBAC kernel, then after that, I went in to create a
"safety" kernel to boot from.  The second kernel compile comes back with a
large number of undefined references in rsbac/rsbac.o
(sys_rsbac_mac_[set,get]_[curr,max]_selelevel, sys_rsback_stats_pm, etc.  

Probably because the defines from the previous compile are there, but
their questions were skipped in defining the recovery kernel.

[snip]

> If you want to try MAC (you have been warned ;):
> - Identify *all* user accounts that need to have shell access (including  
> those that are used via setuid)
> - Set these UIDs to security level confidential (never forget secoff!)
> - If you are using MAC role protection, you need at least one user account  
> that is not secoff, but has at least same security level
> - Set all shells to security level confidential.
> - Set all files written to from shell accounts to confidential or turn on  
> mac_trusted for the programs used for that. Be careful with login  
> information.
> - Start the DNS, SMTP and POP3 with mac_wrap to give them maximum security  
> level 0
> - The *-property enforcement might give you a hell of identifying  
> everything that makes your server processes or shells not work anymore.

This should be a matter of looking in the logs though, right?

> - You will have to turn *-property off for some more programs (mac_trusted  
> to on)
> - I don't like this policy. It is strict, secure, and a mess to use.

Ok, I like MAC, and I think I'll try this approach first, but I'll
probably go pretty slowly. 

> The new Role Compatibility model will make this easier and stronger, the  
> ACL module will at last really do whatever you want.

I'm looking forward to that, the role approach seems to the one of the
easier to deal with.  ACLs are a must IMO.

> 
> You will reduce SMTP risks significantly by using an MTA that need not run  
> as root for accepting of messages, e.g. qmail (my favorite).

I'm currently using postfix, and when I eventually come up with a scheme,
I'd like to backfill RSBAC into the user-id stuff and integrate it into my
system as a part of the "TCB."

> > Scenerio 2:

[snip]
> 
> This szenario cannot be completely done with RSBAC yet. All you could do  
> is restrict access to part of the system for the whole WWW server  
> environment, since there are no compartments implemented in the MAC  
> module. As in szenario 1, access to shells can be limited by MAC, but  
> configuration is a mess.

Hmmm, compartments would help immensely, are they far behind ACLs on the
list of things?

> My recommendation: Wait for Role Compatibility module in 1.0.8 for per-web  
> security. Use SIM and FF to protect the rest of the system now, as in  
> szenario 1.

Ok, I expect to start playing with this now, and then I'll move to the
role-based stuff when it becomes available.

> I agree, and I want to use RSBAC in firewalls, too. The RC and the ACL  
> module will give the kick - at least I hope so.

Once I get some concept systems up, I'll look again at this, and see where
I think I need to go.  I'm still really happy to have such a system to
play with.  My current "realish" (under evaluation) B2 system is going to
be lonely pretty soon.

> If all of you help with bug/success reports, suggestions, advocacy and  
> maybe a few patches this won't be too long away.

I'll do as much as I can.

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.