programming interface for mandatory access controls

fergus fergus at cobbled.net
Mon Aug 25 15:45:44 GMT 2003


i would suggest your assertion/admission that
these are not MAC controls should draw a
conclusion.  however, i'm still unclear as to why
this *isn't* a capabilities model -- even if it's
not mandatory.

in other words, it would be more applicable for
MAC (or perhaps more accurately policy) to have
the facility to make assertions on your privilage
model than integrating the two.

on a tangent . . .

. . . it would be attractive to build a
simple execution/flow model that would allow the
kernel to automatically alter process DAC
(uid/gid and privilages) and MAC (i.e. reduce
classification) during threading / forking /
execing (and perhaps more syscall gates?).  the
primary function of this is _not_ to produce a
behviour model like a syscall interface but to map
a MAC security model to known behaviours.

unfortunately, although i have a clear idea of
enhancements i would like to see from other
TOS/MAC models i've used -- i don't have the
knowledge to asses or attempt it.

On 24.08-12:37, ari wrote:
> Not exactly, no.  What i'm working on is something a bit more like
> discretionary access control, where programs decide for themselves what
> privileges they would like to drop, just as a root-owned process may
> drop its root privileges using setuid(2).  I would actually like to see
> it as readily available as the setuid(2) and chroot(2) calls, despite
> however unlikely that may be to happen anytime in the near future.
> 
> That said, it _is_ possible to implement this using a discretionary
> interface to mandatory access control.  The problem, however, is MAC's
> significant overhead.  I don't believe that this interface _should_ need
> to rely on MAC capabilities being present in the kernel, as dropping
> privileges on demand seems a natural extension of unix principles, as
> opposed to simply an optional programming interface for security
> extensions.  Still, implementing it as a MAC module may be useful and
> effective on many systems.
> 
> If you're still unclear as to what i'm doing (or why i'm doing it), and
> you've viewed the sample code and mailing list archives (there was also
> a similar thread on bugtraq recently), just let me know what specific
> points you have questions or doubts about, and i'll elaborate.
> 
> ari
> 
> 
> evms at bu.edu said this stuff:
> 
> > On Sunday 24 August 2003 09:43 am, ari wrote:
> > > This is in reference to a project that i'm working on:
> > >
> > >   http://www.episec.com/people/edelkind/patches/kernel/flowpriv/
> > >
> > > Please view that site for background information.
> > 
> > I don't understand. Are you trying to reimplement TrustedBSD's MAC
> > capabilities?
> > 
> > Thanks,
> > Evan
> > 
> > - -- 
> > Evan Sarmiento (evms at cs.bu.edu)
> > WWW: http://evms.no-ip.org:8080
> 
> To Unsubscribe: send mail to majordomo at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message

-- 
: fergus cameron                :   [ .]        cobbled    :
: ^^^^^^@cobbled.net            : [ ~][ ]             .net :

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message



More information about the trustedbsd-discuss mailing list