Grsecurity has a compile time option to restrict /sys to root only. This breaks various desktop applications that want read access to /sys When talking with Grsecurity developer (spender) the conclusion was that since this is trivial to fix from userspace, there is no need to add a sysctl option to disable it in kernel space. Attached patch adds an option to disable the SYSFS_RESTRICT from userspace by setting disable_grsec_sysfs_restrict=yes in /etc/conf.d/sysfs. Reproducible: Always
Created attachment 300639 [details, diff] 0001-sysfs-option-to-disable-the-grsecurity-SYSFS_RESTRIC.patch
Comment on attachment 300639 [details, diff] 0001-sysfs-option-to-disable-the-grsecurity-SYSFS_RESTRIC.patch Thanks a lot for the patch. I have a couple of small changes I would like to see though. 1) Please put the code at the bottom of mount_sys() instead of in the main part of the script. 2) Please use "checkpath -m" instead of chmod. This is documented on the runscript man page. 3) Also, add the conf.d/sysfs file into the patch and put it in the Makefile in the conf.d directory. Thanks much.
i'm not sure this is even really useful. if people have to opt into this, can't they just as easily put `chmod 0755 /sys` in their /etc/local.d/ ? alternatively, why don't we just tell people to not use CONFIG_GRKERNSEC_SYSFS_RESTRICT in the first place if they have a system which has code that breaks things ? the *only* thing that define does is set the root dir perms in /sys. so basically, this change only exists to undo 1 kernel config which was enabled in the first place for this reason ...
I agree with Vapier -- more info is needed as to why this is an appropriate work-around rather than simply disabling this feature in the grsec kernel entirely. Adding Piotr Karbowski to cc.
Well I see no real reason why use it, the sysfs hardending in grsecurity is quite annoying and Spender refuse to add special group which could view /sys. As the whole sysfs_restrict feature simply do chmod I think I would stay with adding needed permissions in /etc/local.d/*.start script. Brad says to use chmod to fix it if the permissions are too strict. I say disable it in kernel config and rely on your starup scripts to chmod /sys.
(In reply to comment #3) > i'm not sure this is even really useful. if people have to opt into this, > can't they just as easily put `chmod 0755 /sys` in their /etc/local.d/ ? or I could add a /etc/init.d/sysfs-unrestric script that does only this. Another idea that was discussed was to do this in udev script or the xorg starting stuff. I'd prefer it goes into the sysfs mounting logic so it gets set early. > alternatively, why don't we just tell people to not use > CONFIG_GRKERNSEC_SYSFS_RESTRICT in the first place if they have a system which > has code that breaks things ? the *only* thing that define does is set the > root dir perms in /sys. From the menuconfig help: These filesystems generally provide ac to hardware and debug information that isn't appropriate for unprivileg users of the system. Sysfs and debugfs have also become a large source of new vulnerabilities, ranging from infoleaks to local compromise. There has been very little oversight with an eye toward security involv in adding new exporters of information to these filesystems, so their use is discouraged. So it is a feature that fits for server setups, but it breaks desktop stuff. > so basically, this change only exists to undo 1 kernel config which was enabled > in the first place for this reason ... Yes. What this feature would do is letting users of binary distros use the precompiled hardened kernel without recompile. Also, I prefer to have things locked up by default (which is why it is enabled in first place), and then you open up when you need rather than the opposite - open by default and then you harden. I submitted the patch here because I suspected that gentoo-hardened derivatives might be interested in something similar.
(In reply to comment #5) > I say disable it in kernel > config and rely on your starup scripts to chmod /sys. I prefer hardened by default and open up when needed. Its just painful to need recompile kernel to do so.
(In reply to comment #7) > (In reply to comment #5) > > > I say disable it in kernel > > config and rely on your starup scripts to chmod /sys. > > I prefer hardened by default and open up when needed. Its just painful to need > recompile kernel to do so. There are three predefined GRSEC profiles provided by Gentoo. For WORKSTATION and VIRTUALIZATION, GRKERNSEC_SYSFS_RESTRICT is off by default but the user can turn it on. For SERVER it is forced on. This is as it should be and I don't see a problem. As for it being a pain to recompile a kernel, there are *lots* of other options where a mis-configured kernel means recompiling. Just don't select GRKERNSEC_SYSFS_RESTRICT for desktops.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > > > I say disable it in kernel > > > config and rely on your starup scripts to chmod /sys. > > > > I prefer hardened by default and open up when needed. Its just painful to need > > recompile kernel to do so. > > There are three predefined GRSEC profiles provided by Gentoo. For WORKSTATION > and VIRTUALIZATION, GRKERNSEC_SYSFS_RESTRICT is off by default but the user > can turn it on. For SERVER it is forced on. This is as it should be and I > don't see a problem. And for non-gentoo distros? Or has openrc become a Gentoo-only thing?
Lets drop this. I'll figure out something else. Thanks!
(In reply to comment #9) people misconfiguring their kernels and then trying to get openrc to unmisconfigure them is not a Gentoo-specific issue. what you're asking for is fairly isolated/specific to your use cases, and so doesn't really warrant getting merged into common code. sorry.
