[Labeled-nfs] [RFC] SENFS: MAC labeling support for NFSv4

Casey Schaufler casey at schaufler-ca.com
Thu Aug 2 12:36:04 EDT 2007


--- Stephen Smalley <sds at tycho.nsa.gov> wrote:

> On Thu, 2007-08-02 at 08:26 -0700, Casey Schaufler wrote:
> > --- Stephen Smalley <sds at tycho.nsa.gov> wrote:
> >  
> > > > In the spirit of LSM I suggest that blobs are more appropriate
> > > > units of data than u32s. I understand that the SELinux design
> > > > philosophy is well served by secids. My design philosophy, which
> > > > is pretty much the opposite, has no need for secids and is
> > > > negatively impacted by interfaces that require them.
> > > 
> > > Blobs require full lifecycle management.
> > 
> > Yup.
> > 
> > > secids are lighter weight,
> > 
> > They are lighter weight than big labels. They are heavier than
> > small labels. They require translation, while certain designs of
> > small labels don't even require translation to print.
> 
> I think you'd still lose on the lifecycle management overhead.

Aw, 'cmon. I'm having to add a layer of lifecycle management to
keep secid mappings just so that I can pass them out so that others
can call be back to ask for the original label value. 

I would like to understand why you think I would lose on overhead.
I know you've looked at the Smack code.
 
> > > secids are already entrenched in the LSM interface for labeled
> > > networking
> > 
> > The xfrm interfaces that require secids are seriously SELinux components.
> > Netlabel only uses secids for audit. 
> 
> labeled xfrm isn't limited to SELinux; it could be used by any user of
> labeled networking.

But it isn't, and the xfrm code explictly identifes the messages types
as SELinux specific. If I were adding xfrm to Smack I would not reuse
those types because they strongly identify with SELinux behavior.

> > > and are already entrenched in the audit-selinux interface
> > > (even if converted to using LSM hooks).
> > 
> > So I've found. It is annoying that the audit system passes around sids
> > when it never uses them except to get the associated strings, which
> > Smack uses natively and can provide trivially.
> 
> ...with corresponding lifecycle management overhead.  You'd have to
> allocate and copy at time of audit collection even though the string
> might never be used, versus only allocating and copying upon audit
> record generation.

These copies can be easily avoided using well established
methods. Maybe I'll suggest them for Casey's Audit Update,
phase II.


Casey Schaufler
casey at schaufler-ca.com


More information about the Labeled-nfs mailing list