ls from coreutils 9.6 doesn't show labels of some files

ls from coreutils 9.6 doesn't show labels of some files

[Ondrej Mosnacek]

Hello everyone,

In a recent commit [1] that has already made it into the coreutils
package in Fedora Rawhide, ls changed the way it retrieves security
labels from files, which causes the SELinux label not to be displayed
with -Z for some files. It seems that the key difference is that it
now relies on the result of llistxattr(2) to determine if the label
should be retrieved and if security.selinux is not listed, it just
prints ? as if the file had no label. On some inodes on some
filesystems (e.g. the root inode on tmpfs or most sysfs inodes),
however, security.selinux is not currently returned in *listxattr(2),
so the labels are not shown even though they are there (and would be
returned in a *getxattr(2) call).

We can of course ask coreutils to go back to fetching the label
unconditionally, but perhaps we should also/instead fix the
*listxattr(2) output to be correct? IIUC, in some cases it's a matter
of adding a security_inode_init_security() call, while other ones may
need a hook for listxattr that would inject the security.selinux entry
when it's not returned by the filesystem already.

[1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4ce432ad8738387f1b2e80e883dc7080df3afabe

-- 
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.

Re: ls from coreutils 9.6 doesn't show labels of some files

[Stephen Smalley]

On Tue, Jan 28, 2025 at 10:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> Hello everyone,
>
> In a recent commit [1] that has already made it into the coreutils
> package in Fedora Rawhide, ls changed the way it retrieves security
> labels from files, which causes the SELinux label not to be displayed
> with -Z for some files. It seems that the key difference is that it
> now relies on the result of llistxattr(2) to determine if the label
> should be retrieved and if security.selinux is not listed, it just
> prints ? as if the file had no label. On some inodes on some
> filesystems (e.g. the root inode on tmpfs or most sysfs inodes),
> however, security.selinux is not currently returned in *listxattr(2),
> so the labels are not shown even though they are there (and would be
> returned in a *getxattr(2) call).
>
> We can of course ask coreutils to go back to fetching the label
> unconditionally, but perhaps we should also/instead fix the
> *listxattr(2) output to be correct? IIUC, in some cases it's a matter
> of adding a security_inode_init_security() call, while other ones may
> need a hook for listxattr that would inject the security.selinux entry
> when it's not returned by the filesystem already.
>
> [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4ce432ad8738387f1b2e80e883dc7080df3afabe

There may be other side effects of that commit, e.g. loss of context
translation if using mcstrans or equivalent.
WRT to returning security.selinux, selinux_inode_listsecurity()
already includes the SELinux xattr name so that should already be
returned,
unless the filesystem implements its own listxattr handler for
security.* _and_ doesn't include the SELinux one.

Re: ls from coreutils 9.6 doesn't show labels of some files

[Paul Moore]

On Tue, Jan 28, 2025 at 10:27 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Tue, Jan 28, 2025 at 10:12 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > Hello everyone,
> >
> > In a recent commit [1] that has already made it into the coreutils
> > package in Fedora Rawhide, ls changed the way it retrieves security
> > labels from files, which causes the SELinux label not to be displayed
> > with -Z for some files. It seems that the key difference is that it
> > now relies on the result of llistxattr(2) to determine if the label
> > should be retrieved and if security.selinux is not listed, it just
> > prints ? as if the file had no label. On some inodes on some
> > filesystems (e.g. the root inode on tmpfs or most sysfs inodes),
> > however, security.selinux is not currently returned in *listxattr(2),
> > so the labels are not shown even though they are there (and would be
> > returned in a *getxattr(2) call).
> >
> > We can of course ask coreutils to go back to fetching the label
> > unconditionally, but perhaps we should also/instead fix the
> > *listxattr(2) output to be correct? IIUC, in some cases it's a matter
> > of adding a security_inode_init_security() call, while other ones may
> > need a hook for listxattr that would inject the security.selinux entry
> > when it's not returned by the filesystem already.
> >
> > [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4ce432ad8738387f1b2e80e883dc7080df3afabe
>
> There may be other side effects of that commit, e.g. loss of context
> translation if using mcstrans or equivalent.

Out of curiosity, do we have any idea of the motivation behind that
change?  The commit description is poorly formatted, but it looks like
a number of changes that are only loosely related around xattrs with
the only motivation appearing to be in the subject: "use fewer
xattr-related syscalls".

Regardless, I think Stephen has a good point with the potential for a
loss of translation surprising some users.

> WRT to returning security.selinux, selinux_inode_listsecurity()
> already includes the SELinux xattr name so that should already be
> returned,
> unless the filesystem implements its own listxattr handler for
> security.* _and_ doesn't include the SELinux one.

I can't think of a good reason why we would ever want the *listxattr()
syscalls to not provide security.selinux, if there is an individual
filesystem that is different/broken in this regard it should be
treated as a BUG and fixed.

-- 
paul-moore.com

Re: ls from coreutils 9.6 doesn't show labels of some files

[Rahul Sandhu]

Hey,

> I can't think of a good reason why we would ever want the *listxattr()
> syscalls to not provide security.selinux, if there is an individual
> filesystem that is different/broken in this regard it should be
> treated as a BUG and fixed.

I've spoken to coreutils upstream[1], and they also seem to see this as
something which should be fixed in the kernel too[2][3], and appear to
want a soloution in the kernel rather than working around it in ls(1).

Thanks,
Rahul

[1] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00011.html
[2] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00025.html
[3] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00031.html

Re: ls from coreutils 9.6 doesn't show labels of some files

[Stephen Smalley]

On Tue, Apr 22, 2025 at 12:31 PM Rahul Sandhu <nvraxn@gmail.com> wrote:
>
> Hey,
>
> > I can't think of a good reason why we would ever want the *listxattr()
> > syscalls to not provide security.selinux, if there is an individual
> > filesystem that is different/broken in this regard it should be
> > treated as a BUG and fixed.
>
> I've spoken to coreutils upstream[1], and they also seem to see this as
> something which should be fixed in the kernel too[2][3], and appear to
> want a solution in the kernel rather than working around it in ls(1).

So I assume this was introduced when tmpfs/shmem grew its own xattr
handlers, since previously it would just fall back to the LSM
security_inode_listsecurity() hook and return the SELinux ones
unconditionally. shmem_mknod() calls security_inode_init_security(),
so inodes created after policy is loaded get their security.selinux
xattrs set and returned via listxattr. Root directory of tmpfs mount
and any tmpfs mount that precedes policy load (e.g. initramfs) would
be the exceptions. Could modify shmem_listxattr() to call
security_inode_listsecurity() and combine with its own list before
returning.

>
> Thanks,
> Rahul
>
> [1] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00011.html
> [2] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00025.html
> [3] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00031.html

Re: ls from coreutils 9.6 doesn't show labels of some files

[Dominick Grift]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Tue, Apr 22, 2025 at 12:31 PM Rahul Sandhu <nvraxn@gmail.com> wrote:
>>
>> Hey,
>>
>> > I can't think of a good reason why we would ever want the *listxattr()
>> > syscalls to not provide security.selinux, if there is an individual
>> > filesystem that is different/broken in this regard it should be
>> > treated as a BUG and fixed.
>>
>> I've spoken to coreutils upstream[1], and they also seem to see this as
>> something which should be fixed in the kernel too[2][3], and appear to
>> want a solution in the kernel rather than working around it in ls(1).
>
> So I assume this was introduced when tmpfs/shmem grew its own xattr
> handlers, since previously it would just fall back to the LSM
> security_inode_listsecurity() hook and return the SELinux ones
> unconditionally. shmem_mknod() calls security_inode_init_security(),
> so inodes created after policy is loaded get their security.selinux
> xattrs set and returned via listxattr. Root directory of tmpfs mount
> and any tmpfs mount that precedes policy load (e.g. initramfs) would
> be the exceptions. Could modify shmem_listxattr() to call
> security_inode_listsecurity() and combine with its own list before
> returning.
>

This also happens when you mount an unlabeled fs:

mkdir /media/foo && mount /dev/sda1 /media/foo && ls -alZ /media

when you label it the issue goes away:

chcon sys.id:sys.role:media.file:s0 /media/foo && ls -alZ /media

>>
>> Thanks,
>> Rahul
>>
>> [1] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00011.html
>> [2] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00025.html
>> [3] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00031.html
>

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: ls from coreutils 9.6 doesn't show labels of some files

[Casey Schaufler]

On 4/22/2025 9:31 AM, Rahul Sandhu wrote:
> Hey,
>
>> I can't think of a good reason why we would ever want the *listxattr()
>> syscalls to not provide security.selinux,

If you're using Smack instead of SELinux as an LSM you want to see
security.SMACK64, not security.selinux. Returning a value for security.selinux
makes no sense in this case.

>>  if there is an individual
>> filesystem that is different/broken in this regard it should be
>> treated as a BUG and fixed.
> I've spoken to coreutils upstream[1], and they also seem to see this as
> something which should be fixed in the kernel too[2][3], and appear to
> want a soloution in the kernel rather than working around it in ls(1).
>
> Thanks,
> Rahul
>
> [1] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00011.html
> [2] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00025.html
> [3] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00031.html
>

Re: ls from coreutils 9.6 doesn't show labels of some files

[Stephen Smalley]

On Tue, Apr 22, 2025 at 2:07 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 4/22/2025 9:31 AM, Rahul Sandhu wrote:
> > Hey,
> >
> >> I can't think of a good reason why we would ever want the *listxattr()
> >> syscalls to not provide security.selinux,
>
> If you're using Smack instead of SELinux as an LSM you want to see
> security.SMACK64, not security.selinux. Returning a value for security.selinux
> makes no sense in this case.

As long as they use the security_inode_listsecurity() hook or similar
to fetch the xattr name, it should handle Smack correctly.

>
> >>  if there is an individual
> >> filesystem that is different/broken in this regard it should be
> >> treated as a BUG and fixed.
> > I've spoken to coreutils upstream[1], and they also seem to see this as
> > something which should be fixed in the kernel too[2][3], and appear to
> > want a soloution in the kernel rather than working around it in ls(1).
> >
> > Thanks,
> > Rahul
> >
> > [1] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00011.html
> > [2] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00025.html
> > [3] https://lists.gnu.org/archive/html/bug-coreutils/2025-04/msg00031.html
> >