Re: incorrect sysfs contexts

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

 



On 1/8/20 10:20 AM, Ondrej Mosnacek wrote:
On Wed, Jan 8, 2020 at 4:04 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
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.

Wait... actually I think it should work. I thought for a while that
the xattr would be updated if a node's attribute would differ from its
parent's, but that's not how the kernfs hook works. It will only
explicitly change a child's xattr context if the parent's one has been
explicitly set (which can usually be done only upon a request from
userspace). Sorry for the false alarm.

Looking at the restorecon output above it looks like all the
mislabeled files are symlinks, so this is likely also caused by the
S_ISLNK() exception.

Ok, removing that exception likely requires making it conditional on a new policy capability in order to ensure compatibility with existing policies.




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

  Powered by Linux