Re: [PATCH v2 0/7] Smack namespace

[Lukasz Pawelczyk <l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]

On wto, 2015-05-26 at 12:34 -0400, Stephen Smalley wrote:
> > On wto, 2015-05-26 at 10:35 -0400, Stephen Smalley wrote:
> >> On 05/25/2015 08:32 AM, Lukasz Pawelczyk wrote:
> > 
> > I call the inode operation by hand in the post_setxattr.
> > 
> > The label will effectively be set twice, which is not ideal, but there
> > is no other option right now without reworking the hooks as you said.
> > 
> > This shouldn't really be a problem because the Smack operations will not
> > use the filesystem label (even when it's set incorrectly for a moment)
> > but an already initialized smack_known structure for this inode that has
> > all the values filled in properly.
> > 
> > The only attack vector I can think of is hard rebooting the machine in a
> > way that mapped label is really saved in the filesystem before the
> > unmapped will have a chance. Should I be worried about that? This sounds
> > a little unreal.
> 
> If it were my security module, I would be worried about it.  Even aside
> from maliciously induced failure, you are leaving yourself open to
> inconsistencies arising upon crashes.  I would suggest modifying the
> setxattr hook so that the security module can override the original
> value/size pair with its own definition before it is passed to the inode
> operation.  There is already precedent in that security modules are
> allowed to override the value/size returned by getxattr for security.*,
> so this just makes them fully parallel.

Will do. Thank you.


-- 
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics