[lkml]   [2016]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Problem with setxattr on sockfs with Smack after 971df15bd54ad46e907046ff33750a137b2f0096
On 10/31/2016 2:55 PM, Casey Schaufler wrote:
> Smack has always used extended attributes to identify
> the security information used to make access control
> decisions on packet delivery. The two attributes
> security.SMACK64_IPIN and security.SMACK64_IPOUT
> contain the label used for inbound and outbound
> checks respectively. A process with CAP_MAC_ADMIN can
> change these values using fsetxattr() to allow a
> privileged service to communicate more openly than
> is allowed under the strict Smack policy.
> After the xattr rework the fsetxattr() call still
> sets the Smack attribute correctly, because the
> smack_inode_setxattr() hook is still getting called,
> but it returns EOPNOTSUPP. I believe that this is
> either a result of the attribute name being unknown
> to sockfs (as mentioned in the commit message) or
> one of the other changes made in the process of the
> xattr rework. I haven't finished the bisect yet,
> but I'm reasonably certain the issue arises here.

The final results from bisect say that the problem hit
in 6c6ef9f26e598fb977f60935e109cd5b266c941a -
xattr: stop calling {get,set,remove}xattr inode operations

> Should I add the Smack attributes to the list of
> attributes sockfs acknowledges? Is there a better
> approach?
> Thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to
> More majordomo info at

 \ /
  Last update: 2016-11-01 17:11    [W:0.095 / U:2.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site