The group assigned by "CONFIG_GRKERNSEC_PROC_GID=" cannot access proc with hardened-sources-2.6.34-r1. Applications like gnome-system-monitor and the hardware-monitor applet now crash when attempting to access /proc/vmstat for swap usage statistics. vmstat itself does not work either. I tried switching the special group to "wheel" and changing my main group to wheel but the results are the same. The only user with access still is root. Reproducible: Always Steps to Reproduce: 1. Compile hardened-sources with special proc group 2. Attempt to access /proc from special group Actual Results: Programs trying to access /proc crash and /proc itself is not accessible from special group. Expected Results: Access /proc from special group.
I'm currently running hardened-sources-2.6.34-r1 with CONFIG_GRKERNSEC_PROC_GID=10 (wheel) and I don't seem to be experiencing these problems. Can you post your kernel config so I can compare to mine. Also, there is some misunderstanding about how TPE and GID, see bug #216908. I'm not sure if this is your problem or not, but you may want to check that if you have TPE set.
(In reply to comment #0) > hardware-monitor applet now crash when attempting to access /proc/vmstat for My appologies to the poster, I should have looked more carefully at this. The permissions on this file *did* change between grsec-2.1.14 and grsec-2.2.0. I'll investigate further why and either get upstream to fix or produce a patch. We do want it back.
The change occurs when you have CONFIG_GRKERNSEC_PROC_ADD enabled. The change that was introduced whas that if you have that enabled, then instead of S_IRUGO the file gets the permission S_IRUSR. I argument for it being S_IRUSR | S_IRGRP (i.e. instead of only root has access also the group of your choice has access).
Created attachment 246395 [details, diff] patch against the grsec-patch to show where the trouble lies and how I propose to fix it.
Created attachment 246397 [details, diff] patch against already patched kernel patch against patch? Am I nuts? Here is a patch to be applied on a ready-patched 2.6.34-hardened-r3 kernel-source tree.
(In reply to comment #5) > Created an attachment (id=246397) [details] > patch against already patched kernel > > patch against patch? Am I nuts? Here is a patch to be applied on a > ready-patched 2.6.34-hardened-r3 kernel-source tree. > xake, I think the way to go with this is to disable CONFIG_GRKERNSEC_PROC_ADD for the predefined workstation setting. Changing the permissions on vmstat to 440 would 1) weaken security on all systems including servers and 2) force the user to be a member of the wheel group in order to get vmstat info. The better approach is to simply relax the additional /proc restrictions for workstations, while keeping the the current restrictions for servers. Its an easy change to 4435_grsec-kconfig-gentoo.patch in the hardened-patchset.
> xake, I think the way to go with this is to disable CONFIG_GRKERNSEC_PROC_ADD > for the predefined workstation setting. Changing the permissions on vmstat to > 440 would 1) weaken security on all systems including servers and 2) force the > user to be a member of the wheel group in order to get vmstat info. The better > approach is to simply relax the additional /proc restrictions for workstations, > while keeping the the current restrictions for servers. With hardened-sources-2.6.32-r17 and hardened-sources-2.6.34-r5, the predefined WORKSTATION and WORKSTATION WITHOUT RBAC both have PROC_ADD off by default. With that, apps like gnome-system-monitor work. The option is not forced off, so the user can still choose to turn it on and "break" apps which need to read vmstat, but that's they're choise if they want the added security over functionality. I'm going to close this bug. As always, feel free to reopen if this is not a satisfactory solution.
Hi Anthony, I am re-opening this bug as I do not believe this is the appropriate fix for us. You still run the kernel show these days and I will respect your final decision of course, but please allow me to briefly state my case. I really think that anyone in the CONFIG_GRKERNSEC_PROC_GID ("wheel" by default) group should be considered trusted enough to read /proc/vmstat. I don't see how this provides additional security to deny reads of /proc/vmstat by a group already established as trusted. The mistake is to add anyone you don't trust into this special group in the first place. I know upstream has been making a lot of changes/improvements for security lately (and we 100% appreciate that), but we also have the responsibility of making sure these changes are well-integrated into our distribution. Just like the change-permissions-on-/boot thing we patch out. We also don't want a user to say, well hell I can't enable PROC_GID anymore, but I really need it or I must disable the /proc protections entirely. Security measures are only good if people use them. If they get in the way, people disable them as witnessed by everyone disabling SELinux in RH at the first sign of issues. Thank you for your time and consideration, keep up the great work.
(In reply to comment #8) > Hi Anthony, > > I really think that anyone in the CONFIG_GRKERNSEC_PROC_GID ("wheel" by > default) group should be considered trusted enough to read /proc/vmstat. I remember discussing this with upstream and the feeling was that you shouldn't have to add a user to wheel just to have access to /proc/vmstat as it gives other privileges you may not want that user to have. This convinced me because it seems like overkill to add a desktop user to wheel in order to have apps like gnome-system-monitor work. To be clear: you're suggesting that I revert the change to 4435_grsec-kconfig-gentoo.patch and adopt xake's approach?
(In reply to comment #9) > (In reply to comment #8) > > Hi Anthony, > > > > I really think that anyone in the CONFIG_GRKERNSEC_PROC_GID ("wheel" by > > default) group should be considered trusted enough to read /proc/vmstat. > > I remember discussing this with upstream and the feeling was that you shouldn't > have to add a user to wheel just to have access to /proc/vmstat as it gives > other privileges you may not want that user to have. This convinced me because > it seems like overkill to add a desktop user to wheel in order to have apps > like gnome-system-monitor work. > I agree with that entirely, to do so would be a misconfiguration by the user. No one is forcing anyone to use the "wheel" group for this feature, its just the most sane default we could provide (because wheel is generally a trusted group) given the available groups. If the user only wants to grant the permissions afforded by GRKERNSEC_PROC_GID and not those granted by being a member of "wheel", they should create and use a separate group (ex. "grsecproc"). Kerin and I actually wanted to have the hardened-sources ebuild add special groups for these types of features (the socket one, etc). However, there are issues in the way gentoo manages groups that basically makes this impossible. I forget who was working on a GLEP to address the group-management issue. I'm not sure if it went anywhere (and I'm as much at fault for that as I had hoped to help with that GLEP and couldn't make the time). If you'd like to chat about this sometime I can explain some of the approaches we came up with and what their caveats/shortcomings (bad enough to make it a no-go) are. > To be clear: you're suggesting that I revert the change to > 4435_grsec-kconfig-gentoo.patch and adopt xake's approach? > Yes sir. Because anyone in "wheel" (our default) is considered trusted IMO. Adding untrusted users to "wheel" is a misconfiguration. Would you add untrusted users to "wheel" or "root"? Adding users to "wheel" just to give them access to /proc is also a misconfiguration and doesn't make sense. If access to stuff under /proc is all that is needed, the fact is you have specific needs we are incapable of meeting at this time and need to create a separate group yourself.
Putting the request for reconsideration on hold for the moment, ignore for now.
Resolved with grsecurity upstream. We've gone the route of changing the help text for the GRKERNSEC_PROC_USERGROUP option to be consistent with the options' current scope/intent. Currently the help text states that GRKERNSEC_PROC_USERGROUP grants access to "...view all processes, network-related information, and kernel and symbol information. This option is useful if you want to run identd as a non-root user." The option has always been intended for such low-level daemon processes and trusted (at least somewhat) users. But as others have stated earlier, this has been recently further locked-down. The option can now be described like this: "...view all processes and network-related information. This option is useful if you want to run identd as a non-root user." Such daemons and users should not really need access to information about kernel symbols, internals, etc. Using the identd daemon example (on a recent grsec kernel), should said daemon (or similar) be compromised it would not have access to information about the kernels' memory management internals that /proc/vmstat affords -- which can assist in further exploitation to gain further elevated privileges. Unfortunately, this will break for some people/scripts who's ideas about this option are based on its more-permissive past-designs. I think the answer to that is this grsecurity option was being less restricted than it was meant to be, needed to be "fixed"... and it is indeed fixed these days. Finally, the help text in the next grsec patch should finally reflect that too. Possible workarounds (if you must): -Patch the kernel to work the way you want -Change group and/or group perms on the particular item you want on startup -Make mark suid or make an suid wrapper around anything needing /proc/vmstat -Disable the more-restrictive GRKERNSEC_PROC_ADD option -Use RBAC instead (more fine-grained control) I cannot really recommend any of these except the last one. ;) Just keep in mind that /proc/vmstat contains potentially useful information for exploitation and another suid binary is, well, another suid binary... Closing as 'FIXED'.
You may also be interested in sys-apps/dstat, which provides similar functionality to 'vmstat' without needing to read from /proc/vmstat.
