Re: Implementation questions

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: Implementation questions
Date: 14 Jan 1999 13:35:00 +0100
Next Article (by Subject): Re: Implementation questions "Paul D. Robertson"
Previous Article (by Subject): Implementation questions "Paul D. Robertson"
Top of Thread: Implementation questions "Paul D. Robertson"
Next in Thread: Re: Implementation questions "Paul D. Robertson"
Articles sorted by: [Date] [Author] [Subject]
********* ***************** ********** ****  *****   ***** ************
  To subject Implementation questions
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

> On 11 Jan 1999, A. Ott wrote:
>
> > The problem magically disappeared when I ported to 2.2.0-pre6.
>
> 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.

> Now I'm about ready to start playing, I have some scenerios that I'd like
> feedback on prior to implementation.

Go ahead...

> Scenerio 1:
>
> DNS/SMTP/POP server.  Ultimately, I'd like to be sure that neither the SMTP
> or DNS server's compromise could lead to shell access under any
> circumstances.  I'd also like to restrict configuration file changes to a
> limited group of people who could only change those files that are
> necessary, but with an audit of what was changed and when.

Easiest way for restricted file change: Use SIM module and declare  
everything not to be changed as security information. Only people with  
role security_officer are allowed to change them. Root is definately not  
(this was SIM's original purpose).

Turn on SIM role protection, because otherwise compromised root processes  
could simply change UID. This way you cannot login as a security officer  
directly, instead you have to login as a normal user and use
su -l secoff with password.

Turn on individual logging and set logging of WRITE_OPEN, APPEND_OPEN,  
READ_WRITE_OPEN, RENAME, LINKHARD, MODIFY_ATTRIBUTE (did I forget  
anything?) to full for all relevant files. If one secoff changes logging  
stuff, it will be recorded as MODIFY_ATTRIBUTE - scan for that in the log.

Turn on RSBAC own logging. This gives you another request logging source  
in /proc/rsbac-info/rmsg, usable by secoffs only - now admins and secoffs  
can control each other -> see MODIFY_ATTRIBUTE logging above...

The shell stuff is a bit different. First you have to protect the /etc/ 
shells and all relevant binary files. Use FF module and set them to  
read_only or execute_only (binaries only, shell must read_open scripts).  
You can set it at dir level (e.g. for /bin), and the files will inherit  
the flags. Check with effective mode in rsbac_fd_menu.

You could even set everything that need not be changed during normal  
operation to read_only, and remove that flag for installation etc.


Currently there is no way to restrict exec, unless using MAC or PM module - 
or making the programs object_type security (FC) and all normal users  
security officers.
PM and MAC are both dangerous in that you can easily lock yourself out.  
Also they are complex. I don't recommend PM for this szenario, it's for a  
too different purpose.

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


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

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

> Scenerio 2:
>
> HTTP server.  As with the above, I'd like to restrict compromise to the
> running server itself.  I'd also like to have per-Web user/group access
> security on the content under some directory trees.  Per-user/group CGI
> restrictions and the ability to stop a CGI programmer from giving a shell
> would also be nice.  Ultimately, user permissions (shell, read/change,
> etc.) would also be based on some sort of trusted path or IP scheme
> (possibly per-interface in its most rudimentry form)
>
> I think both of these can be done with MAC level authorizations and
> authentications on traditional B-? systems.  What I'm looking for here is
> some suggestions on an approach with RSBAC, what pieces I have now, what
> I should wait for, and how easy it's going to be to configure and maintain.

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.

Everything else from szenario 1 should be used here, too.

Additionally, you could use MAC role protection. This prevents the web  
server from going back to a higher security level - root always has  
top_secret, normal users (like wwwrun) usually have less. This reduces  
functionality though.


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.

RC approach:
- Set one restricted role for the server UID. This role is not compatible  
with other roles (the role cannot be changed by the process). It is not  
compatible with anything but served files and served sockets.
- The server binaries and config files are security information (SIM  
module) and thus protected against tampering
- use the RC_force_role entry on CGI files (inheritable from dir) to set  
only these processes temporarily to another role (e.g. CGI) with extra  
rights - until they exec again.
- Of course the forced role won't be compatible to files of type shell,  
unless explicitely granted.
- The whole server stuff can run in any UID, because it is restricted by  
the roles. Even root or setuid root on CGIs won't be a problem, unless  
there are flaws in RSBAC or setup.
- Update of webs can be easily restricted to single roles each, what means  
one role per user. As soon as the ACL module is finished, this can be more  
restrictive and based on UIDs / files and dirs, removing all number  
limits. Since roles are set on setuid, any update mechanism can be used  
that supports UIDs (proper authentification security will be addressed,  
too).
- All (CGI) change accesses can be logged via individual logging.
- Note that no change to the web server is necessary

> Scenerio 2 seems to be the most useful to me at the moment, as I think
> real-world secure Web servers executing untrusted content is a serious
> void.  If we can get Apache to play nicely with RSBAC, there's potential
> for such systems.

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.

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

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.