Re: Request for discussion

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: Request for discussion
Date: 27 Dec 1998 14:37:00 +0100

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

********* ***************** ********** ****  *****   ***** ************
  To subject Re: Request for discussion
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

> On the better late than never theory:

:)

> > For RSBAC 1.0.6 (or later) I would like to discuss a few ideas I had:
> >
> > Already implemented:
> >
> > - Module File Flags allows to set some flags for files and dirs. Currently
> >   there are 3:
> >   - execute only (files): Only execute requests are allowed
> >   - read only (files and dirs): All write/change requests are denied
> >   - search only (dirs): Only name lookups in the kernel are allowed, so
> >     all file/subdir accesses must include the path, no ls etc. is granted
> >   What other flags would you be interested in?
>
> Write only would be interesting if read/change access can be denied, that
> way processes with a short time of ownership of sensative data could
> write it out, but compromise of the process would lead only to compromise
> of currently held information.

OK, I will add that. Writing will have to include create in dirs then, and  
inheritance does the rest.

Another one just added is add_inherited. This works like the other  
inheriting mechanisms, but all inherited attributes are added (or'd) to  
those existing at the first place. So you can simply mark a dir as  
read_only, and all files and subdirs get read_only added - if they have  
add_inherited, which is the default value. If single files must be  
protected as execute_only, just add that attribute. Read_only is still  
inherited (though a subset of execute_only).

> Should execute only extend to directories as well?

No, because I want them to be inherited. And I don't like the Unix  
interpretation of 'execute' on dirs. So I would rather add another one,  
chdir_only - meaningful for chroot processes only anyway, I think.

> > - RSBAC logging can be done via own RSBAC routines (printk/sys_syslog
> >   clone) with restricted access. Old style logging via standard syslog can
> >   be turned off.
> >   Problem: We need a patched klogd to read the log and write it somewhere
> >   else. How can this be provided for all RSBAC systems?
> Perhaps a module or interception of printk()?

No, this is clearly user space. I patched an older version of klogd, but a  
tail -f /proc/rsbac-info/rmsg >logfile should do for now.

> > - ACI version update: If the previous ACI version is detected, it is
> >   upconverted. Do we need several steps, increasing kernel size (and
> >   work), or only support for the previous official release?
> Maybe a single-user mode program to convert from prior versions with
> automatic support for the previous official release?

There is no user mode access to the files, and there should be none. So it  
must be in the kernel. Currently they are converted on read (= mount time)  
and marked as dirty, so they are written as soon as possible in the new  
format. This process is repeatable because of the version number.

> > - Access Control Lists (ACL): Quite easily a new module for this could be
> >   added, giving individual user rights based on request type to objects. A
> >   special user RSBAC_ALL_USER already exists and could be used for general
> >   access. A special right would be to extend own rights to others.
> >   Administration could be done in Netware style, and if no access entry
> >   for a requesting user is present at this object, it could be inherited
> >   from the parent object or from a group (see above). Security officers
> >   could play the admin role, e.g. if no entry has been defined so far.
> >
> >   How do you think about it? Is there any need to include this?
>
> I think ACLs should be included, I'll look over some other
> implementations and see how the admin stuff stacks up.

My original plans have already been much extended. There will be a  
flexible role based module, on top of which the ACL stuff can be placed.  
So we have ACL for roles and users on all targets.

> Hope some of this is useful,

Sure.

Amon.

--
Please remove second ao for E-Mail reply - no spam please!
## 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.