Re: Implementation questions

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: Implementation questions
Date: 20 Jan 1999 19:10:00 +0100

Next Article (by Date): Re: Implementation questions Alvaro Jose Fernandez Lago
Previous Article (by Date): Re: Implementation questions "Paul D. Robertson"
Top of Thread: Implementation questions "Paul D. Robertson"
Next in Thread: Re: Implementation questions Alvaro Jose Fernandez Lago
Articles sorted by: [Date] [Author] [Subject]

********* ***************** ********** ****  *****   ***** ************
  To subject Re: Implementation questions
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

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

I will look into it. Looks like rsbac/help/syscalls.c was not linked in,  
or at least not recompiled. Must be a dependency problem, maybe some  
indirect includes. Strange. Did you try a make dep ; make clean? Did that  
help?

> > If you want to try MAC (you have been warned ;):
> > - 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?

As long as you can still look into them. ;)

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

You can still use the other ones additionally, they won't hurt you.

BTW: The mac_trusted_for_user flag on files allows setting the mac_trusted  
on processes executing this program only for single users, which will  
allow stricter security settings.

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

The Role Compatibility model is quite far coded by now, the data  
structures and the syscalls seem to work correctly. All that is missing is  
the decision part, which is not that difficult, and of course testing it  
out. Another two days of work and first tests, whenever I find the time.

After that I want to put up a first pre-version to let you test it, too.

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

To be honest, noboby really asked for that before, and I like the RC model  
more, which will give much more flexible 'compartments'. So I did not code  
it. It's not that much work, though, because sets have already been  
implemented in the PM code. Cut and paste are your friends...

Do you want me to add compartments to MAC, or will RC do the job for you?

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

As told above, it is a matter of a few weeks to get it running. I had a  
short intermezzo with better backup support for inode-independent stuff  
(like roles and types) in /proc/rsbac-info/backup/. Some day I will put  
the PM stuff in there, too.

Try the simpler models first to get a feeling of the behaviour, and you  
can work through the logging model, if you want.

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

Which one?

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

Thanks a lot. It's much more fun, if it's appreciated by others.

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.