Robert Watson wrote:

> FWIW, I think comparing kauth(9) and SELinux is somewhat silly.  :-)

Yes, obvious.. I simplified an ealier question, asking what do we need
a SELinux-like environment in NetBSD for, and what need of our users
can't kauth(9) -- due to its design limitations -- address. :)

> Now you can argue about whether the lack of ability to specify labels
> independent from the traditional uid/gid model is useful, which is
> probably the better comparison.  That can then drive a decision about
> whether you need a more capable framework, or for that matter extensions
> to kauth(9), in order to support those requirements.  The design
> decisions behind LSM and the MAC Framework reflect the labeling
> requirements of more comprehensive system policies with information
> labeling requirements, whereas kauth(9) doesn't. If you don't need the
> labeling capability, then kauth(9) meets your needs, but if you do need
> the labeling capability, then kauth(9) doesn't.  Nothing precludes
> having multiple frameworks, for that matter -- kauth(9) to provide a
> simpler programming interface for simple policies, and a more
> comprehensive framework for more comprehensive policies.  Or providing
> one interface using another -- this is what SELinux does, btw.  FLASK is
> a more constrained security interface layered on top of LSM, which deals
> with a "sid" labeling abstraction, rather than kernel data structures
> for objects.  Likewise with SEBSD -- FLASK is layered over the MAC
> Framework on FreeBSD and Mac OS X.

I completely agree. There is no argument that kauth(9) is less capable
than the MAC framework (or LSM) -- but the discussion was about whether
we, and the NetBSD userbase, *need* the extra complexity introduced by
having such subsystems.

Like I said before, I would not object a port of the MAC framework (or
similar work required to implement SELinux) to NetBSD, and in fact
encourage people to do so. However, I don't think -- and after this
discussion even more so -- that this is something we'd like to see in
our base system.

-e.

--
Elad Efrat