Brightness keys don't work without root

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

Brightness keys don't work without root

Postby onzin » Sat Jan 28, 2017 2:32 pm

Hi,

I'm running openSUSE with the grsec kernel built by OBS by someone else. I have a problem with setting brightness with my brightness keys, as well as shutdown and reboot without sudo. I've traced the problem to pkexec and perhaps polkit. Pkexec actually doesn't work at all, with any program I try, although sudo can set brightness manually. So I'm not sure this is a grsec issue, but I don't know enough about it to rule it out. If someone would shed light on this, and perhaps possible ways to fix it, I would appreciate it. Note that I talked to the person building the kernel, and he was not aware of a fix.

pkexec[25780]: user: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/user] [COMMAND=/usr/lib/gnome-settings-daemon-3.0/gsd-backlight-helper --set-brightness 264]

Thanks.
onzin
 
Posts: 2
Joined: Sat Jan 28, 2017 2:07 pm

Re: Brightness keys don't work without root

Postby spender » Sat Jan 28, 2017 2:55 pm

Not much to go on with this amount of detail. I'd need to see your kernel config for starters, particularly if CONFIG_GRKERNSEC_SYSFS_RESTRICT is enabled (it shouldn't be enabled on desktops). As for shutdown/reboot, perhaps polkit is trying to perform those actions while running in a chrooted process with CAP_SYS_BOOT (which we disallow for chrooted processes). You could try disabling CONFIG_GRKERNSEC_CHROOT_CAPS to test that theory (or echo 0 > /proc/sys/kernel/grsecurity/chroot_caps)

Security-wise, polkit/sudo/etc are a bad idea as they destroy the compartmentalization of privilege that exists with dedicated administrative accounts. Without strict RBAC in place, you're easily one trojan/backdoor (via .bashrc or whatever else) away from having a compromise of your user account extend to the administrative actions you allow to be performed from that account.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: Brightness keys don't work without root

Postby onzin » Sun Jan 29, 2017 2:49 pm

Thanks a lot for your reply Brad. CONFIG_GRKERNSEC_SYSFS_RESTRICT is indeed disabled for the kernel. I set CONFIG_GRKERNSEC_CHROOT_CAPS to 0, but to no avail.

I pasted the kernel config here: http://pastebin.com/Xwc9imXA
If you could take a quick look, it would be very much appreciated!

Concerning the use of polkit/sudo/etc, yeah... I started realising since a short while ago how insecurely I use my computers, and am eager to change that. I will look into RBAC and adapt it as soon as possible. I guess if you would recommend a secure distro it would be something like Alpine or Qubes?

Thanks again.
onzin
 
Posts: 2
Joined: Sat Jan 28, 2017 2:07 pm

Re: Brightness keys don't work without root

Postby timbgo » Sun Jan 29, 2017 7:00 pm

onzin wrote:Thanks a lot for your reply Brad. CONFIG_GRKERNSEC_SYSFS_RESTRICT is indeed disabled for the kernel. I set CONFIG_GRKERNSEC_CHROOT_CAPS to 0, but to no avail.

I pasted the kernel config here: http://pastebin.com/Xwc9imXA
If you could take a quick look, it would be very much appreciated!

[ I'm not an expert, that's first ].
And I didn't inspect it in details, no time.
But I can say I do see far too many modules compiled in there. One of the rules of a secure system is to enable only those modules that you need. But you'd need to duckduck.com for it how it's done on OpenSUSE. I know that on Gentoo I have, as far as firmware, maybe 95% or more, of what installs by default, disabled (firmware and modules go together often, not always).

onzin wrote:Concerning the use of polkit/sudo/etc, yeah... I started realising since a short while ago how insecurely I use my computers, and am eager to change that. I will look into RBAC and adapt it as soon as possible. I guess if you would recommend a secure distro it would be something like Alpine or Qubes?

Thanks again.

Haven't yet tried Qubes. I searched previously, and the good thing about Alpine is they base their system on grsecurity. But it's an old grsecurity, not supported by grsecurity developers here. Not necessarily bad!

But I prefer going with the free-testing grsecurity, and with the main, spender and PaX Team developed grsec.

If you're not afraid of work, Gentoo is, if you go with the grsecurity-hardened OpenRC (systemD is bad IMO), potentially very secure. But it is likely the hardest distro, nerds only stay with it... ;-) Potential use: for virtually anything, packages base probably most numerous of all distros...

And grsecurity is at home, and I really hope it will stay at home for almost ever and a few more days, in Gentoo, like in no other distro...

By the way, there's no good kernel these days if these two guys here, that I mentioned above, haven't fixed it. Without grsec, it's very very poor security the Linus' kernel... Sorry to be blunt, but that's how I have been conviced, ever again, it has been the case, since long... (pls. see the link in my signature about when it started and read it carefully)

Regards!
---
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am


Return to grsecurity support