From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: Request for discussion
Date: Sat, 26 Dec 1998 09:13:13 -0500 (EST)
Next Article (by Subject): Re: Request for discussion ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Request for discussion ao@morpork.shnet.org (A. Ott)
Top of Thread: Request for discussion ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Request for discussion ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date]
[Author]
[Subject]
On 14 Nov 1998, A. Ott wrote:
> Hi RSBAC folks!
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.
Should execute only extend to directories as well?
> - 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()?
> - 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?
> - 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.
Hope some of this is useful,
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 "Paul D. Robertson" <proberts@clark.net> 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: Request for discussion ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Request for discussion ao@morpork.shnet.org (A. Ott)
Top of Thread: Request for discussion ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Request for discussion ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date]
[Author]
[Subject]