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

[Dominick Grift <dominick.grift@defensec.nl>]

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