|
Bugzilla – Full Text Bug Listing |
| Summary: | AUDIT-WHITELIST: gnome-branding-Aeon: review of sudo and polkit configuration for openSUSE Aeon | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Aeon | Reporter: | Richard Brown <rbrown> |
| Component: | Base | Assignee: | Matthias Gerstner <matthias.gerstner> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | filippo.bonazzi, lnussel, wolfgang.frisch |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Richard Brown
2023-09-13 06:58:25 UTC
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. |