From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: Implementation questions
Date: Tue, 19 Jan 1999 12:06:06 -0500 (EST)
Next Article (by Subject): Re: Implementation questions ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Re: Implementation questions 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.
Next Article (by Subject): Re: Implementation questions ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Re: Implementation questions 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]