linux-kernel - Re: Problem with setxattr on sockfs with Smack after 971df15bd54ad46e907046ff33750a137b2f0096

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bf76b2ed-0974-2bae-a9f8-5bf40d30d20e@schaufler-ca.com>
Date:   Tue, 1 Nov 2016 09:10:49 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Andreas Gruenbacher <agruenba@...hat.com>,
        Al Viro <viro@...IV.linux.org.uk>
Cc:     LKLM <linux-kernel@...r.kernel.org>,
        LSM <linux-security-module@...r.kernel.org>
Subject: Re: 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 majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>