Request for discussion

From: ao@morpork.shnet.org (A. Ott)
Subject: Request for discussion
Date: 14 Nov 1998 12:36:00 +0100

Next Article (by Author): rm -r hang patch ao@morpork.shnet.org (A. Ott)
Previous Article (by Author): 1.0.5 on 2.1.126 / shm.c ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Request for discussion "Paul D. Robertson"
Articles sorted by: [Date] [Author] [Subject]

Hi RSBAC folks!

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?

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

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

Future ideas:

- Inheritance of attributes: Files and subdirs can inherit attribute
  values from their parent dirs, groups of users might be added. I thought
  about a special attribute value 'inherit' used as standard value for all
  attributes that should be inherited.
  Problem: Support for inheritance would mean some major changes in the
  file/dir representation in the request and set_attr calls to the
  decision (ADF) and in the get/set_attr calls to the data structures
  component, meaning lots of work.

  Is it worth it? I think yes.

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

- A simple transaction type could be added, copying a file on write-open
  and replacing the file on close. This would mean a major change in linux
  functions though.

  Useful? Needed?

Hope to get some feedback,

Amon.

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