improve hide-hardware-info.service, make /sys hiding optional

[monsieuremre]

A systemd service restricts /proc/cpuinfo, /proc/bus, /proc/scsi and /sys to the root user. This hides a lot of hardware identifiers from unprivileged users and increases security as /sys exposes a lot of information that shouldn't be accessible to unprivileged users. As this will break many things, it is disabled by default and can optionally be enabled by executing systemctl enable hide-hardware-info.service as root.

Ok.

Although not tested, I am almost 100% sure practically all the breakage is caused by restricting /sys. My recommendation is, we leave this one out. Add /proc/kallsyms to the list as well, as this contains all the memory addresses for each kernel symbol. And enable what we already have, restricting the sub-directories under proc.

Should I follow with the respective pull?

[adrelanos]

I am not sure how that PR would look but I guess rather small.

Since this is not enabled by default and for extra security, I tend to add what you suggested here.

Worth trying.

[monsieuremre]

Actually we do not even need that service I think. We can set the permissions using the permission hardener service. We are just going to do these with the already existing permission hardener service.

chmod 400 /proc/kallsyms
chmod 400 /proc/cpuinfo
chmod 500 /proc/bus

And that's it. This hides a lot of hardware and kernel info. And I am pretty positive it won't break anything.

[adrelanos]

hide-hardware-info.service issues:

• broken flatpak example (flatpak run org.chromium.Chromium)
• Xfce restart and shutdown button

But these are all probably related to /sys.

Could you test please if these work?

related:
https://www.kicksecure.com/wiki/Security-misc#Restrict_Hardware_Information_to_Root

[adrelanos]

Actually we do not even need that service I think. We can set the permissions using the permission hardener service. We are just going to do these with the already existing permission hardener service.

That's an interesting idea to get rid of the extra service. Nice in theory, but...

Could you check please what other features the current implementation has?

• https://github.com/Kicksecure/security-misc/blob/master/lib/systemd/system/hide-hardware-info.service
• https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/hide-hardware-info

chmod 400 /proc/kallsyms
chmod 400 /proc/cpuinfo
chmod 500 /proc/bus

Nice idea but permission-hardener no longer runs at boot time. Only at package install time or when run manually. This was changed to fix the slow/broken boot issues. But changes to /proc (or /sys) need to be done at boot time since these are virtual file systems which are created during boot.

Even only hide-hardware-info.service was reported to slow down the boot process.

So I guess the best way here is to improve hide-hardware-info.service?

• harden more (the 3 items you suggested)
• harden all except /sys by default?
  • /sys only opt-in due to the issues.

[monsieuremre]

harden more (the 3 items you suggested)

2 of them are already in I think, so we just have to add the one.

harden all except /sys by default?

Yessir. This is the one only cause of breakage, in my observation at least.

[adrelanos]

Ok.

PR to update the script run by hide-hardware-info.service would be welcome.

• Do the doable by default.
• /sys opt-in.
• The systemd unit file enhancements? sysinit-post.target (Similar to remount-secure.service.)

[adrelanos]

This one seems really cool and doable.

Ping @monsieuremre

[monsieuremre]

I remember having tested this locally some time ago. Adding /proc/kallsyms to the list and disabling /sys. It worked but I think one of the other stuff had to be disabled as well, but I have to check again I'm not sure. I think this would be incomplete without doing /proc also.

But also, I remember I have found a way better solution for this thing after doing all the tests. That's when I created the full system policy. It is now merged with apparmor.d. So I would recommend focusing on packaging @roddhjav's package for whonix, which it now natively supports. We don't need to enable the full system policy even to have the protections for these stuff. Especially with the new apparmor version it is possible to have profiles for unconfined processes. We can make sure these paths are only reachable by certain applications that are have their dedicated apparmor profiles. This way, we would protect the entirety of /proc, /sys, and everything else also literally.

I have seen @roddhjav create profiles from mere log files before. See this one. I am sure if we provide the project with enough data points, he might be able to work something out for xfce too and the full system policy would also for for whonix, we would also be involved of course, as much as we could.

I think this should be prioritized no matter what. But as our fallback protection, as I said, I will create a pull for this issue, in some time.

[monsieuremre]

As I said, I did draft some solution that also addresses this issue. It seems to work for file permissions dynamically. I think it can be implemented for mounting things as well (have to try out first).

But for sensitive proc, I think I found a better way. We can modify the mount options. Procfs has the mount option subset. We can set this to the subsets that we want to be available. If we set the option subset=pid, then pid is visible to everyone (the default), but everything else invisible, including /proc/dma /proc/consoles /proc/cmdline /proc/iomem and like a billion other things you can check them with ls /proc. I know for a fact that hiding memory access and device stuff and kernel arguments is good and does not break anything. i am not sure what can be hidden here without breakage, but I will test and find out the optimal mount options for proc. My ideal scenario would be to implement this amoung other mount options in a daemon that I have already suggested in another post. I think this can be done, and would probably be for the good. Otherwise, we can always go kernel params for extra mount options if you do not like the daemon idea.

[monsieuremre]

So basically, I have this one but I gotta say. While we are at it, let's hide pid too. Our workaround solution is not good enough because like things with pkexec don't work. I see. Users under the group proc are exempt from our hardening. So like, why don't we just set group id for the pkexec binary. We will set the group id as proc for pkexec (or anything at all that might break). Like Stuid and setgid are not cool security wise, but we are sgid'ing to group rpoc, which is non root, only proc privileges. So worst case some program that uses pkexec may elevate privileges to get access to prov (literally requires vulnerability in the os), which still would be like, no issue because thats basically what we have as of now. Did you consider this? Has this been tried.

[adrelanos]

Created

• sgid (set-group-ID) pkexec to fix hidepid #201

for it.

[DanWin]

While debugging another issue, I figured out that /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 is trying to stat /sys/fs/cgroup/ but failing and then exiting because of it. When I allow access to this path, the polkit agent is running and the password prompt working. To address this, we would need to allow access to /sys, but can block anything under /sys/* except for /sys/fs/ which needs to be accessible by the polkit agent. Then we can again block access to anything under /sys/fs/*
With those changes polkit is working as expected.

[adrelanos]

related to flatpak:

• Test whether sysfs mountpoints are accessible before mounting them flatpak/flatpak#5697

[monsieuremre]

Hoping to track within the PR from now on, so closing.

[adrelanos]

A smaller change only required here, not mixed with remounting.

[adrelanos]

#202 had interesting suggestions.

chmod 0500 /sys/block
#chmod 0500 /sys/class
#chmod 0500 /sys/devices
#chmod 0500 /sys/fs
chmod 0500 /sys/kernel
chmod 0500 /sys/power
chmod 0500 /sys/bus
#chmod 0500 /sys/dev
chmod 0500 /sys/firmware
chmod 0500 /sys/hypervisor
chmod 0500 /sys/module

[adrelanos]

This is what's happening after merging #204.

usr/libexec/security-misc/hide-hardware-info: INFO: START
INFO: whitelist executing: chgrp --quiet --recursive cpuinfo /proc/cpuinfo
INFO: whitelist executing: chmod o-rwx /proc/cpuinfo
INFO: normal executing   : chmod og-rwx /proc/bus
INFO: normal executing   : chmod og-rwx /proc/scsi
INFO: whitelist executing: chgrp --quiet --recursive sysfs /sys
INFO: whitelist executing: chmod o-rwx /sys
INFO: normal executing   : chmod o-rwx /sys/block
INFO: normal executing   : chmod o-rwx /sys/bus
INFO: normal executing   : chmod o-rwx /sys/class
INFO: normal executing   : chmod o-rwx /sys/dev
INFO: normal executing   : chmod o-rwx /sys/devices
INFO: normal executing   : chmod o-rwx /sys/firmware
INFO: normal executing   : chmod o-rwx /sys/fs
INFO: normal executing   : chmod o-rwx /sys/hypervisor
INFO: normal executing   : chmod o-rwx /sys/kernel
INFO: normal executing   : chmod o-rwx /sys/module
INFO: normal executing   : chmod o-rwx /sys/power
INFO: normal executing   : chmod o-rwx /sys/fs/bpf
INFO: normal executing   : chmod o-rwx /sys/fs/btrfs
INFO: normal executing   : chmod o-rwx /sys/fs/cgroup
INFO: normal executing   : chmod o-rwx /sys/fs/ext4
INFO: normal executing   : chmod o-rwx /sys/fs/fuse
INFO: normal executing   : chmod o-rwx /sys/fs/pstore
INFO: normal executing   : chmod o+rx /sys /sys/fs
usr/libexec/security-misc/hide-hardware-info: INFO: END

Needs testing.

[adrelanos]

But for sensitive proc, I think I found a better way. We can modify the mount options. Procfs has the mount option subset. We can set this to the subsets that we want to be available. If we set the option subset=pid, then pid is visible to everyone (the default), but everything else invisible, including /proc/dma /proc/consoles /proc/cmdline /proc/iomem and like a billion other things you can check them with ls /proc. I know for a fact that hiding memory access and device stuff and kernel arguments is good and does not break anything. i am not sure what can be hidden here without breakage, but I will test and find out the optimal mount options for proc.

Created,

• remount-secure: use procfs mount option subset (hide-hardware-info.service) #205

for it.

[adrelanos]

flatpak: thanks to #204 this is now fixed.

---

#202 had interesting suggestions.

chmod 0500 /sys/block
#chmod 0500 /sys/class
#chmod 0500 /sys/devices
#chmod 0500 /sys/fs
chmod 0500 /sys/kernel
chmod 0500 /sys/power
chmod 0500 /sys/bus
#chmod 0500 /sys/dev
chmod 0500 /sys/firmware
chmod 0500 /sys/hypervisor
chmod 0500 /sys/module

These are all covered by default.

/proc/kallsyms

Created,

• hide-hardware-info.service: hide /proc/kallsyms #206

for it.

[adrelanos]

For enable hide-hardware-information.service by default, please open a separate ticket if you wish to suggest that.

All was implemented what has been discussed in this ticket or follow-up tickets have been created. If something has been forgotten, I guess small, actionable follow-up tickets would be the most productive.

hide-hardware-information.service known issues:
https://www.kicksecure.com/wiki/Security-misc#Reduce_Kernel_Information_Leaks_-_Known_Issues