Bugzilla – Bug 1215276
AUDIT-WHITELIST: gnome-branding-Aeon: review of sudo and polkit configuration for openSUSE Aeon
Last modified: 2023-10-04 11:27:20 UTC
Hi security team, Aeon has the explicit goal of being a more user friendly, straight of the box, less maintenance required desktop-only OS As a result, the current builds use gnome-initial-setup for creating the first user account, not YaST. We're also working hard on distributing Aeon as images that don't have/use a root account (https://bugzilla.opensuse.org/show_bug.cgi?id=1213159) In order to facilitate that, we're aiming for a configuration that does the following: - sudo configured to allow the wheel group to do privileged actions, requiring the password of that user (not targetpw) - polkit configured to allow the wheel group to do privileged actions, requiring the password of that user The account made by gnome-initial-setup is already in the wheel group The changes for the above sudo and polkit are on the way to Factory but got rightly stuck because I didn't file this audit till now: https://build.opensuse.org/request/show/1109759 Please audit and whitelist so I can get things moving :) If there is concern regarding SUSE products - Aeon is separate from both MicroOS and Tumbleweed, this branding package is called Aeon and it's as mean as possible to conflict with everything so it shouldn't be possible to accidentally slip into any SUSE product. There are no plans AFAIK for SUSE to do any product based on what I'm doing in Aeon
Thank you for opening this AUDIT bug. We will schedule it in our team shortly.
As part of this effort, I would propose that we add the proactive-security OBS group as a reviewer of the devel:microos:aeon/systemd-presets-branding-Aeon package, as we did for Base:System/systemd-presets-branding-openSUSE.
(In reply to Filippo Bonazzi from comment #2) > As part of this effort, I would propose that we add the proactive-security > OBS group as a reviewer of the > devel:microos:aeon/systemd-presets-branding-Aeon package, as we did for > Base:System/systemd-presets-branding-openSUSE. Done!
I will have a look into this.
This is the sudoers drop in configuration file: $ cat /etc/sudoers.d/50-aeon Defaults:%wheel !targetpw %wheel ALL = (root) ALL So users in the wheel group will be able to run commands as root providing their own password. And then there is the polkit rules file: $ cat /usr/share/polkit-1/rules.d/49-aeon.rules polkit.addAdminRule(function(action, subject) { return ["unix-group:wheel"]; }); This is a similar setting on Polkit level that grant members of the wheel group an admin identity. In openSUSE there have been repeated discussions regarding the meaning of the wheel group. There is a group of people that consider members of the wheel group to be equivalent to root, without even entering any password. We rejected this notion for openSUSE - especially because gnome-initial-setup by default adds the initial user account to the wheel group. For Aeon, since this is an explicit design decision, targeted towards desktop single-user setups, such an approach is acceptable. Also because users still need to enter their own account password to escalate privileges. Granting root privileges without any password entry should be avoided though. I will start the whitelisting process for the two files. Note that we tie our whitelistings to the digest of the files seen during review. If the content changes then a follow-up review will be required.
Can we somehow make sure that this package is not added to openSUSE Tumbleweed? For it the special circumstances don't apply and I wouldn't want it to end up there.
(In reply to Matthias Gerstner from comment #6) > Can we somehow make sure that this package is not added to openSUSE > Tumbleweed? For it the special circumstances don't apply and I wouldn't want > it to end up there. I could add a hard requires on the Aeon-release package So even though the package will be in the Tumbleweed repo (that’s unavoidable) then the only way of installing it would be on Aeon
Or maybe more sensibly a hard conflicts with the Tumbleweed and MicroOS release packages..either way though I think we’re adding an extra layer than absolutely necessary because anyone installing this package will obviously be wanting to get the Aeon config that’s part of the Aeon design goals
Either way , thanks for the speedy review!
Chiming in here. IMO the sudo and polkit settings do actually make sense to have in a separate package (sudo-branding-wheel-is-root?) that can be installed on regular TW. The nice thing about this solution is that it does not impact the current behavior for users that are not in the wheel group. So this way is safe upgrade wise. It neither promotes all kinds of users to admin, nor does it lock out everyone. Previous attempts to simply remove targetpw suffered from those problems. So +1 from my side. My only concern ins the choice of the name of the group. SUSE as OS vendor did intentionally not use it for any purpose so it was left to site admins to use for whatever purpose they like. So in certain deployments having those settings might be dangerous. Therefore my gut feeling tells me to use a different name for the group (Debian uses a group named 'sudo' IIRC).
We are mostly concerned about this change in policy silently becoming part of some pattern or being Required/Recommended somewhere, because somebody believes it's a good idea. There is probably no easy technical measure to prevent this while still allowing opt-in installation of the package.
the whitelisting is on its way to Factory in the rpmlint package
This is an autogenerated message for OBS integration: This bug (1215276) was mentioned in https://build.opensuse.org/request/show/1111551 Factory / rpmlint
Ubuntu uses this for polkit, less javascript: $ cat /usr/share/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf [Configuration] AdminIdentities=unix-group:sudo;unix-group:admin
This is an autogenerated message for OBS integration: This bug (1215276) was mentioned in https://build.opensuse.org/request/show/1111949 Factory / rpmlint
This is an autogenerated message for OBS integration: This bug (1215276) was mentioned in https://build.opensuse.org/request/show/1111991 Factory / rpmlint
The whitelisting is through, closing as fixed.