linux-kernel - Re: [PATCH] selinux: Fix SBLABEL

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 30 Mar 2017 13:27:07 -0400
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        "J. Bruce Fields" <bfields@...hat.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        James Morris <james.l.morris@...cle.com>, selinux@...ho.nsa.gov
Subject: Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote:
> On 29 March 2017 at 23:34, J. Bruce Fields <bfields@...hat.com>
> wrote:
> > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote:
> > > Labelling of files in a NFSv4.2 currently fails with ENOTSUPP
> > > because
> > > the mount point doesn't have SBLABEL_MNT.
> > > 
> > > Add specific condition for NFS4 filesystems so it gets correctly
> > > labeled.
> > 
> > Huh.  Looking at the code, I think this is meant to be handled by
> > the
> > SECURITY_FS_USE_NATIVE case--there was a similar failure fixed some
> > time
> > ago by 9fc2b4b436cf.  What kernel are you seeing this on?  Is it a
> > recent regression (in which case, what's the latest kernel that
> > worked
> > for you)?
> 
> I have seen this on 4.11-rc4, but I never tried to get this working
> before.
> 
> I will try to find time to see why SECURITY_FS_USE_NATIVE isn't
> working here.

Does your exports file specify the "security_label" option, e.g.
/path/to/dir example.com(rw,security_label)

It appears that with recent kernels that is now required; otherwise,
the mount defaults to not enabling native labeling and all of the files
are treated as having a single, fixed label defined by the client
policy (and hence setxattr is not supported).  This was kernel commit
32ddd944a056c786f6acdd95ed29e994adc613a2.  I don't recall seeing any
discussion of this on selinux list.  I understand the rationale, but it
seems like a user-visible regression and at the very least, it seems
odd that they didn't just use "seclabel" as the kernel does in
/proc/mounts to signify a filesystem that supports security labeling by
userspace.