[Bug 1125432] New: AUDIT-0: gnome-initial-setup: purpose of /usr/share/polkit-1/rules.d/20-gnome-initial-setup.rules
http://bugzilla.suse.com/show_bug.cgi?id=1125432 Bug ID: 1125432 Summary: AUDIT-0: gnome-initial-setup: purpose of /usr/share/polkit-1/rules.d/20-gnome-initial-setup.rul es Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: qzhao@suse.com Reporter: matthias.gerstner@suse.com QA Contact: qa-bugs@suse.de CC: security-team@suse.de Found By: --- Blocker: --- As explained in bug 1125314 we are currently looking into polkit rules files installed into /usr/share/polkit-1/rules.d. In the future we want to apply a whitelisting restriction to rule files installed there. gnome-initial-setup installs the rules file /usr/share/polkit-1/rules.d/20-gnome-initial-setup.rules. These rules probably never went through a review with the security team. Since the file starts with '20-' it will take precedence over our polkit-default-privs. This rules file allows the user "gnome-initial-setup" to perform any of the following actions without password authentication, if coming from a local session: org.freedesktop.udisks2.filesystem-mount-system org.freedesktop.hostname1.* org.freedesktop.NetworkManager.* org.freedesktop.locale1.* org.freedesktop.packagekit.system-sources-configure org.freedesktop.accounts.* org.freedesktop.timedate1.* org.freedesktop.realmd.* org.freedesktop.RealtimeKit1.* That is quite a lot of power. Can you explain under which circumstances this gnome-initial-setup user is coming into play? How is the user logged in, does he have a password and so on. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
Matthias Gerstner
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c1
--- Comment #1 from Matthias Gerstner
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c2
--- Comment #2 from Cliff Zhao
org.freedesktop.udisks2.filesystem-mount-system org.freedesktop.hostname1.* org.freedesktop.NetworkManager.* org.freedesktop.locale1.* org.freedesktop.packagekit.system-sources-configure org.freedesktop.accounts.* org.freedesktop.timedate1.* org.freedesktop.realmd.* org.freedesktop.RealtimeKit1.*
That is quite a lot of power. Can you explain under which circumstances this gnome-initial-setup user is coming into play? How is the user logged in, does he have a password and so on.
Gnome-initial-setup is a setup tool which will run in the first time of user login to desktop, which is just like gnome-control-center. So the reason is user will set these values for desktop through G-I-S. By SLE's customization: Before this program runs, the user has already authorized by GDM, he must input the correct password. Thanks -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c3
--- Comment #3 from Cliff Zhao
A new rpmlint-check is effective in Factory by now that generates a warning about files installed in rules.d without a whitelisting. In a while we will make this an error.
Please not, this is not an error. Gnome-initial-setup needs it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c4
--- Comment #4 from Matthias Gerstner
(In reply to Matthias Gerstner from comment #0) ...
org.freedesktop.udisks2.filesystem-mount-system org.freedesktop.hostname1.* org.freedesktop.NetworkManager.* org.freedesktop.locale1.* org.freedesktop.packagekit.system-sources-configure org.freedesktop.accounts.* org.freedesktop.timedate1.* org.freedesktop.realmd.* org.freedesktop.RealtimeKit1.*
That is quite a lot of power. Can you explain under which circumstances this gnome-initial-setup user is coming into play? How is the user logged in, does he have a password and so on.
Gnome-initial-setup is a setup tool which will run in the first time of user login to desktop, which is just like gnome-control-center. So the reason is user will set these values for desktop through G-I-S.
But the actions are only authorized for the 'gnome-initial-setup' user, not for the actually logged in user. The spec file creates the user explicitly: ``` $ id gnome-initial-setup uid=445(gnome-initial-setup) gid=100(users) groups=100(users) ``` So under which circumstances does the gnome-initial-setup package employ the gnome-initial-setup user? I couldn't find any usage of this user. The polkit actions are only used in the G-I-S code if the mode is `GIS_DRIVER_MODE_NEW_USER`. Who is supposed to run /usr/lib/gnome-initial-setup under this 'gnome-initial-setup' user?
By SLE's customization: Before this program runs, the user has already authorized by GDM, he must input the correct password.
The actions above are actions that often require the root password like most of the NetworkManager actions. Especially packagekit.system-sources-configure requires the root password. So the user authorization is not enough to be worry-free here. To me it looks like most of these actions aren't used at all any more in the G-I-S code. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c5
--- Comment #5 from Matthias Gerstner
(In reply to Matthias Gerstner from comment #1)
A new rpmlint-check is effective in Factory by now that generates a warning about files installed in rules.d without a whitelisting. In a while we will make this an error.
Please not, this is not an error. Gnome-initial-setup needs it.
It will be an error from the security perspective if we don't review it ;-) So please let's find out together in which context the actions are used and whether the rules are actually needed (any more). If they are used and needed then we need to review the code that calls the actions and whitelist the rules file if all is well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c6
--- Comment #6 from Cliff Zhao
(In reply to qzhao@suse.com from comment #2)
(In reply to Matthias Gerstner from comment #0) ...
org.freedesktop.udisks2.filesystem-mount-system org.freedesktop.hostname1.* org.freedesktop.NetworkManager.* org.freedesktop.locale1.* org.freedesktop.packagekit.system-sources-configure org.freedesktop.accounts.* org.freedesktop.timedate1.* org.freedesktop.realmd.* org.freedesktop.RealtimeKit1.*
That is quite a lot of power. Can you explain under which circumstances this gnome-initial-setup user is coming into play? How is the user logged in, does he have a password and so on.
Gnome-initial-setup is a setup tool which will run in the first time of user login to desktop, which is just like gnome-control-center. So the reason is user will set these values for desktop through G-I-S.
But the actions are only authorized for the 'gnome-initial-setup' user, not for the actually logged in user. The spec file creates the user explicitly:
``` $ id gnome-initial-setup uid=445(gnome-initial-setup) gid=100(users) groups=100(users) ``` Sorry, I'm not very familier with polikit, maybe omitted it, :)
So under which circumstances does the gnome-initial-setup package employ the gnome-initial-setup user? I couldn't find any usage of this user. The polkit actions are only used in the G-I-S code if the mode is `GIS_DRIVER_MODE_NEW_USER`. Who is supposed to run /usr/lib/gnome-initial-setup under this 'gnome-initial-setup' user?
Currently, "new-user" mode has been disabled by our customization. if these policies only take effect here, the will not be run. But we should be aware that in the future this module may be enabled again. So I think to open these policies is absolutely one work for all benefits.
By SLE's customization: Before this program runs, the user has already authorized by GDM, he must input the correct password.
The actions above are actions that often require the root password like most of the NetworkManager actions. Especially packagekit.system-sources-configure requires the root password. So the user authorization is not enough to be worry-free here.
I think we don't need to be too cautious: First, these policies are inherited from the upsteam, fedora/debian/ubuntu... even BSD all use these privilege, I don't see any complaint about it. Second is, If you close these rights, and in the future, some release manager request to re-open "new user mode", the customer user experience will be extremely bad, I think. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c7
--- Comment #7 from Matthias Gerstner
I think we don't need to be too cautious: First, these policies are inherited from the upsteam, fedora/debian/ubuntu... even BSD all use these privilege, I don't see any complaint about it.
Sorry but this reasoning does not work out at all. We wouldn't need to do any security reviews by these standards. Just have a look at the various security issues uncovered by SUSE employees in upstream software [1]. [1]: https://www.google.de/search?q=site:https://seclists.org/oss-sec/+suse
Second is, If you close these > rights, and in the future, some release manager request to re-open "new user mode", the customer user experience will be extremely bad, I think.
The correct way will be to ask for a security review when this happens and then we will be on the safe side. There is no way around the security review: Either we do it right now, thereby wasting resources for a feature currently not in use (and for a version of the software that will most probably never be used) or we remove the rules file and do the review when it's actually needed. I vote for the latter. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c9
--- Comment #9 from Matthias Gerstner
g-i-s is auto-logged in by GDM 'if there is no user configured on the system'.
So the code for this is found in GDM then?
on TW, this feature was not 'patched to death'
What do you mean by that? Did somebody patch it to death somewhere? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c10
--- Comment #10 from Dominique Leuenberger
(In reply to dimstar@opensuse.org from comment #8)
g-i-s is auto-logged in by GDM 'if there is no user configured on the system'.
So the code for this is found in GDM then?
correct. e.g. ./daemon/gdm-launch-environment.c: return create_gnome_session_environment ("gnome-initial-setup",
on TW, this feature was not 'patched to death'
What do you mean by that? Did somebody patch it to death somewhere?
on SLE (and I thihk also Leap) g-i-s was patched down to basically only do 'keyboard layout selection' for 'more complex areas' like China
From the g-i-s spec file:
# PATCH-FEATURE-SLE gnome-initial-setup-only-launch-CJK.patch FATE#321126 qzhao@suse.com -- Make gnome-initial-setup only work for CJK Patch0: gnome-initial-setup-only-launch-CJK.patch # PATCH-FEATURE-SLE gnome-initial-setup-only-setup-keyboard.patch FATE#321126 yfjiang@suse.com -- Only launch the keyboard and IM setup Patch1: gnome-initial-setup-only-setup-keyboard.patch -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c11
--- Comment #11 from Matthias Gerstner
(In reply to Matthias Gerstner from comment #9)
(In reply to dimstar@opensuse.org from comment #8)
g-i-s is auto-logged in by GDM 'if there is no user configured on the system'.
So the code for this is found in GDM then?
correct. e.g.
./daemon/gdm-launch-environment.c: return create_gnome_session_environment ("gnome-initial-setup",
Okay, thanks for the additional information. I will see whether I can find out more about the involved polkit rules and whether they're used any more and if so, whether they're used correctly. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c13
--- Comment #13 from Matthias Gerstner
g-i-s is auto-logged in by GDM 'if there is no user configured on the system'. On openSUSE Tumbleweed for example, this can be achieved by 'skipping user creation' in the yast installer (or using an autoyast profile, for OEMs delivering hardware with preinstalled OS).
Hmm I still can't see this implemented anymore. I just tested a fresh Tumbleweed installation but nothing special happened when skipping user creation. The system boots into gdm and it asks me for username/password as usual. When you look into the gdm code in function `gdm_local_display_prepare()` then `gdm_create_initial_setup_launch_environment()` is only called when the `doing-initial-setup` property is set to true. However, this property is read-only (G_PARAM_READABLE) and I can't find any place where it is ever set to true. Maybe I'm still doing something wrong or looking at a wrongly patched version of gdm (the one from openSUSE:Factory). Also the polkit rules in question are not used within gdm as well. It wouldn't need to since it runs as root anyways. Gut the g-i-s code doesn't use most of them as well any more. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c16
--- Comment #16 from Matthias Gerstner
(In reply to Matthias Gerstner from comment #13)
Hmm I still can't see this implemented anymore. I just tested a fresh Tumbleweed installation but nothing special happened when skipping user creation. The system boots into gdm and it asks me for username/password as usual.
was gnome-initial=setup installed? I haven't tested this in a while now, so well possible we broke it on the way (but that would be unintentional)
Indeed after manually installing g-i-s and restarting xdm the logic is triggered. But then the question is how this is supposed to work when g-i-s is not installed in this situation ;-). I still wonder where in the code the exact decision is made to run in this mode. Having this logic spread across different packages and obviously in a badly maintained state on as well the upstream end as well as our own end gives me a bad feeling security wise. If this should turn out to be a niche feature that is actually broken and nobody noticed then we should consider dropping it (at least the polkit part). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c17
--- Comment #17 from Dominique Leuenberger
(In reply to dimstar@opensuse.org from comment #15)
(In reply to Matthias Gerstner from comment #13)
Hmm I still can't see this implemented anymore. I just tested a fresh Tumbleweed installation but nothing special happened when skipping user creation. The system boots into gdm and it asks me for username/password as usual.
was gnome-initial=setup installed? I haven't tested this in a while now, so well possible we broke it on the way (but that would be unintentional)
Indeed after manually installing g-i-s and restarting xdm the logic is triggered. But then the question is how this is supposed to work when g-i-s is not installed in this situation ;-).
if g-i-s is not installed, gdm basically falls back to the 'old' style asking for username/password. If no user can login, it's the admins task to make the system usable without any help (other than yast... as it always was before g-i-s was avaialble)
I still wonder where in the code the exact decision is made to run in this mode.
I can try to find it, but from memory, it should be GDM deciding it: if no users exist to show in the login picker (i.e UID >= 1000) it attempts to run g-i-s (as specific user) - and if this fails, it falls back to the username/password prompt.
Having this logic spread across different packages and obviously in a badly maintained state on as well the upstream end as well as our own end gives me a bad feeling security wise. If this should turn out to be a niche feature that is actually broken and nobody noticed then we should consider dropping it (at least the polkit part).
The login manager is the 'thing' that know if there are logins available and that can try to run a service to 'fix' it (in this case g-i-s). g-i-s then is the implementation of the service fixing it. And as you confirmed, it seems not broken. when no user is created, and g-i-s is present, the service comes up as expected -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c18
--- Comment #18 from Dominique Leuenberger
I still wonder where in the code the exact decision is made to run in this mode.
I can try to find it, but from memory, it should be GDM deciding it: if no users exist to show in the login picker (i.e UID >= 1000) it attempts to run g-i-s (as specific user) - and if this fails, it falls back to the username/password prompt.
Specifically: in GDM:/daemon/gdm-display.c gdm_display_prepare (GdmDisplay *self) { … self->priv->doing_initial_setup = wants_initial_setup (self); … } static gboolean wants_initial_setup (GdmDisplay *self) { … /* don't run initial-setup on remote displays */ … /* don't run if the system has existing users */ if (self->priv->have_existing_user_accounts) { return FALSE; } … /* don't run if initial-setup is unavailable */ if (!can_create_environment ("gnome-initial-setup")) { return FALSE; } … } -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c19
--- Comment #19 from Matthias Gerstner
And as you confirmed, it seems not broken. when no user is created, and g-i-s is present, the service comes up as expected
Technically it is not broken but what is the intended workflow for a regular end-user to end up in this mode when g-i-s is not installed by default? So it would be only for AutoYaST or something like that. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c20
--- Comment #20 from Dominique Leuenberger
Technically it is not broken but what is the intended workflow for a regular end-user to end up in this mode when g-i-s is not installed by default?
So it would be only for AutoYaST or something like that.
It is indeed mostly targeting autoyast profiled auto-installations. Commonly used by OEMs pre-shipping openSUSE- having the final setup done by the user (very common practice) it COULD be integrated into the standard workflow of OS setup, but that would make the default install experience between desktops too large - which is why we (GNOME Team) opted against having it preinstalled by default (we want to stay as similar as possible between other DEs like KDE and GNOME.. but not offering this anymore for integrations would be a step back) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1125432
http://bugzilla.suse.com/show_bug.cgi?id=1125432#c21
Matthias Gerstner
participants (1)
-
bugzilla_noreply＠novell.com