[PATCH v2 0/7] Smack namespace
l.pawelczyk at samsung.com
Tue May 26 16:42:35 UTC 2015
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.
Samsung R&D Institute Poland
More information about the Containers