lkml.org 
[lkml]   [2015]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 0/7] Smack namespace
From
Date
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





\
 
 \ /
  Last update: 2015-05-26 19:21    [W:0.044 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site