Re: incorrect sysfs contexts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/8/20 8:34 AM, Ondrej Mosnacek wrote:
On Wed, Dec 18, 2019 at 4:35 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 12/18/19 10:13 AM, Christian Göttsche wrote:
Hi,

I am trying to refine contexts of sysfs.

When using genfscon statements like:
      genfscon sysfs /  system_u:object_r:sysfs_t:s0
      genfscon sysfs /class/net  system_u:object_r:net_sysfs_t:s0
      genfscon sysfs /devices  system_u:object_r:generic_device_sysfs_t:s0
      genfscon sysfs /devices/system/cpu  system_u:object_r:cpu_sysfs_t:s0
      genfscon sysfs /devices/system/cpu/online
system_u:object_r:cpu_online_sysfs_t:s0
      genfscon sysfs /firmware  system_u:object_r:firmware_sysfs_t:s0
      genfscon sysfs /module/apparmor  system_u:object_r:apparmor_sysfs_t:s0

and file context definitions like:
      /sys(/.*)?
gen_context(system_u:object_r:sysfs_t,s0)
      /sys/module/apparmor(/.*)?
gen_context(system_u:object_r:apparmor_sysfs_t,s0)
      /sys/devices/system/cpu(/.*)?
gen_context(system_u:object_r:cpu_sysfs_t,s0)
      /sys/devices/system/cpu/online          --
gen_context(system_u:object_r:cpu_online_sysfs_t,s0)
      /sys/firmware(/.*)?
gen_context(system_u:object_r:firmware_sysfs_t,s0)
      /sys/devices(/.*)?
gen_context(system_u:object_r:generic_device_sysfs_t,s0)
      /sys/devices/.*/sd[a-z](/.*)?
gen_context(system_u:object_r:harddrive_sysfs_t,s0)
      /sys/devices/.*/hwmon(/.*)?
gen_context(system_u:object_r:hwmon_sysfs_t,s0)
      /sys/class/net(/.*)?
gen_context(system_u:object_r:net_sysfs_t,s0)
      /sys/devices/.*/net(/.*)?
gen_context(system_u:object_r:net_sysfs_t,s0)

with a systemd tmpfiles entry:
      #Type Path        Mode UID  GID  Age Argument
      Z     /sys        -    -    -    -   -

I still get incorrect labeled entries after boot:

$ restorecon -v -R -n /
Would relabel /sys/devices/platform/intel_rapl_msr.0/subsystem from
system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/0-0:AD1980/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/controlC0/device
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/controlC0/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D1c/device
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D1c/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D0c/device
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D0c/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/device
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D0p/device
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0
Would relabel /sys/devices/pci0000:00/0000:00:05.0/sound/card0/pcmC0D0p/subsystem
from system_u:object_r:sysfs_t:s0 to
system_u:object_r:generic_device_sysfs_t:s0

Using auditallow statements reveals no accesses.

How can I enforce these entries to be created with correct labels?

kernel version? v5.2 introduced improved sysfs/kernfs support for
inheritance of SELinux labels, circa commit
e19dfdc83b60f196e0653d683499f7bc5548128f ("kernfs: initialize security
of newly created nodes").

That's correct, since v5.2 the full-name genfs labeling will not work,
you will have to substitute these rules with filename type transitions
(or set the labels manually).

Wait...is that really true? If so, that's a kernel-userspace interface regression, which isn't permitted. New kernel with old policy must continue to provide the same behavior. Android certainly relies upon extensive labeling of sysfs nodes.







[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux