Permissions in the udevadm_t domain

Permissions in the udevadm_t domain

[Laurent Bigonville]

(Re-sending it because thunderbird decided to send it in HTML...)

Hello,

One of the remaining blocker to have (a very minimal) debian buster boot 
in enforcing mode with the refpolicy is systemd-udev-trigger.service 
which call udevadm

On my test VM I see the two following denials:

----
type=PROCTITLE msg=audit(06/09/19 18:32:23.171:98) : proctitle=/bin/udevadm trigger --type=devices --action=add
type=PATH msg=audit(06/09/19 18:32:23.171:98) : item=0 name=/run/udev/data/+platform:QEMU0002:00 inode=12544 dev=00:15 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:udev_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(06/09/19 18:32:23.171:98) : cwd=/
type=SYSCALL msg=audit(06/09/19 18:32:23.171:98) : arch=x86_64 syscall=openat success=yes exit=5 a0=0xffffff9c a1=0x7ffd84825cc0 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=1140 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
type=AVC msg=audit(06/09/19 18:32:23.171:98) : avc:  denied  { open } for  pid=1140 comm=udevadm path=/run/udev/data/+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(06/09/19 18:32:23.171:98) : avc:  denied  { read } for  pid=1140 comm=udevadm name=+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
----
type=PROCTITLE msg=audit(06/09/19 18:32:23.175:99) : proctitle=/bin/udevadm trigger --type=devices --action=add
type=SYSCALL msg=audit(06/09/19 18:32:23.175:99) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0x5 a1=0x7ffd84825be0 a2=0x7ffd84825be0 a3=0x0 items=0 ppid=1 pid=1140 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
type=AVC msg=audit(06/09/19 18:32:23.175:99) : avc:  denied  { getattr } for  pid=1140 comm=udevadm path=/run/udev/data/+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1

And

type=PROCTITLE msg=audit(29/08/19 15:37:14.505:417) : proctitle=/bin/udevadm trigger --type=subsystems --action=add
type=PATH msg=audit(29/08/19 15:37:14.505:417) : item=0 name=/sys/module/snd_hda_codec_generic/uevent inode=17769 dev=00:13 mode=file,200 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(29/08/19 15:37:14.505:417) : cwd=/
type=SYSCALL msg=audit(29/08/19 15:37:14.505:417) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission non accordée) a0=0xffffff9c a1=0x7fff23710260 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=481 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc:  denied  { dac_override } for  pid=481 comm=udevadm capability=dac_override  scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0
type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc:  denied  { dac_read_search } for  pid=481 comm=udevadm capability=dac_read_search  scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0

For the former, adding read_files_pattern(udevadm_t, udev_var_run_t, 
udev_var_run_t) fixes the issues (and then the VM boots fine). But when 
looking at the current policy code I'm seeing that udevadm is allowed to 
delete files/directory/.. in /var/run and I'm wondering why. I've never 
seen this happening during my (limited) test, an idea?

For the later, it seems that the kernel the mode to 400 on some files in 
/sys (ie. --w------- 1 root root 4096 sep  5 17:06 
/sys/module/snd_hda_codec_generic/uevent) looking at the code it seems 
that udev is ready to handle EACCES already, so I was wondering, should 
we just allow dac_read_search or don't audit dac_read_search (and 
dac_override as well then)?

I can provide patches if you want

Kind regards,

Laurent Bigonville

Re: Permissions in the udevadm_t domain

[Nicolas Iooss]

[Adding selinux-refpolicy@vger.kernel.org, which is better suited for
questions related to refpolicy]

On Sat, Sep 7, 2019 at 12:19 PM Laurent Bigonville <bigon@debian.org> wrote:
>
> (Re-sending it because thunderbird decided to send it in HTML...)
>
> Hello,
>
> One of the remaining blocker to have (a very minimal) debian buster boot
> in enforcing mode with the refpolicy is systemd-udev-trigger.service
> which call udevadm
>
> On my test VM I see the two following denials:
>
> ----
> type=PROCTITLE msg=audit(06/09/19 18:32:23.171:98) : proctitle=/bin/udevadm trigger --type=devices --action=add
> type=PATH msg=audit(06/09/19 18:32:23.171:98) : item=0 name=/run/udev/data/+platform:QEMU0002:00 inode=12544 dev=00:15 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:udev_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
> type=CWD msg=audit(06/09/19 18:32:23.171:98) : cwd=/
> type=SYSCALL msg=audit(06/09/19 18:32:23.171:98) : arch=x86_64 syscall=openat success=yes exit=5 a0=0xffffff9c a1=0x7ffd84825cc0 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=1140 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
> type=AVC msg=audit(06/09/19 18:32:23.171:98) : avc:  denied  { open } for  pid=1140 comm=udevadm path=/run/udev/data/+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
> type=AVC msg=audit(06/09/19 18:32:23.171:98) : avc:  denied  { read } for  pid=1140 comm=udevadm name=+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
> ----
> type=PROCTITLE msg=audit(06/09/19 18:32:23.175:99) : proctitle=/bin/udevadm trigger --type=devices --action=add
> type=SYSCALL msg=audit(06/09/19 18:32:23.175:99) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0x5 a1=0x7ffd84825be0 a2=0x7ffd84825be0 a3=0x0 items=0 ppid=1 pid=1140 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
> type=AVC msg=audit(06/09/19 18:32:23.175:99) : avc:  denied  { getattr } for  pid=1140 comm=udevadm path=/run/udev/data/+platform:QEMU0002:00 dev="tmpfs" ino=12544 scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:object_r:udev_var_run_t:s0 tclass=file permissive=1
>
> And
>
> type=PROCTITLE msg=audit(29/08/19 15:37:14.505:417) : proctitle=/bin/udevadm trigger --type=subsystems --action=add
> type=PATH msg=audit(29/08/19 15:37:14.505:417) : item=0 name=/sys/module/snd_hda_codec_generic/uevent inode=17769 dev=00:13 mode=file,200 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sysfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
> type=CWD msg=audit(29/08/19 15:37:14.505:417) : cwd=/
> type=SYSCALL msg=audit(29/08/19 15:37:14.505:417) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission non accordée) a0=0xffffff9c a1=0x7fff23710260 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=481 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=udevadm exe=/usr/bin/udevadm subj=system_u:system_r:udevadm_t:s0 key=(null)
> type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc:  denied  { dac_override } for  pid=481 comm=udevadm capability=dac_override  scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0
> type=AVC msg=audit(29/08/19 15:37:14.505:417) : avc:  denied  { dac_read_search } for  pid=481 comm=udevadm capability=dac_read_search  scontext=system_u:system_r:udevadm_t:s0 tcontext=system_u:system_r:udevadm_t:s0 tclass=capability permissive=0
>
> For the former, adding read_files_pattern(udevadm_t, udev_var_run_t,
> udev_var_run_t) fixes the issues (and then the VM boots fine).

Nice :) Could you please send a patch for this, or open a Pull Request
on https://github.com/SELinuxProject/refpolicy?

> But when
> looking at the current policy code I'm seeing that udevadm is allowed to
> delete files/directory/.. in /var/run and I'm wondering why. I've never
> seen this happening during my (limited) test, an idea?

Which policy? On my test system based on a lightly-patched refpolicy, I have:

# sesearch -A -s udevadm_t -t var_run_t
allow udevadm_t var_run_t:dir { getattr open search };
allow udevadm_t var_run_t:lnk_file { getattr read };

> For the later, it seems that the kernel the mode to 400 on some files in
> /sys (ie. --w------- 1 root root 4096 sep  5 17:06
> /sys/module/snd_hda_codec_generic/uevent) looking at the code it seems
> that udev is ready to handle EACCES already, so I was wondering, should
> we just allow dac_read_search or don't audit dac_read_search (and
> dac_override as well then)?

For the record, even with dac_read_search, opening this file fails
with EACCES, because the kernel did not implement show() on this sysfs
file (cf. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/module.c?h=v5.2#n1204
and kernfs_fop_open() in fs/kernfs/file.c). More precisely, openat()
returns EACCES because kernfs_fop_open() returns this error code when
trying to open a write-only file for reading. Unfortunately this check
happens after the capability checks, which is why you got the denials
for dac_override and dac_read_search.

I do not have an opinion about allowing dac_read_search vs.
dontaudit-ing dac_read_search and dac_override.

Kind regards,
Nicolas