Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login
Control: retitle -1 accountsservice: User that seemed to have been deleted via gnome-control-center can still login Control: reassign -1 accountsservice 22.08.8-1 Control: affects -1 gnome-control-center Control: forwarded -1 https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107 On Wed, 01 Feb 2023 at 22:32:40 +, Simon McVittie wrote: > When accountsservice is deciding whether an account is local, it assumes > that the only accounts that are local are the ones in its list of accounts > from /etc/shadow, *after* filtering. ... > I think this is a bug. I think this is the main cause here, and from source code inspection, there are probably ways to trigger it even without Debian's patches. Reported upstream as https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107 > gnome-control-center is not exactly helping here, by not having a > particularly clear indication of whether it thinks an account is local > or remote I reported https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2326 but I think that's out-of-scope for this bug report (and realistically we are not going to redesign this piece of UI before bookworm). If anyone wants to work on that, please take it upstream. smcv
Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login
On Wed, 01 Feb 2023 at 21:07:09 +, Simon McVittie wrote: > Looking briefly at the gnome-control-center code, I think this indicates > that act_user_is_local_account() is returning false, so instead of deleting > a local user, gnome-control-center is telling accountsservice to > "uncache" a remotely-managed (enterprise) user? I don't know what practical > effect that has, but it doesn't sound like a true "delete" operation? This seems to be a side-effect of new user accounts accidentally being created with nologin as their shell (#1030253). This indirectly makes accountsservice, and therefore gnome-control-center, think that it's a remotely-managed account (from LDAP or equivalent). When accountsservice reads /etc/passwd and /etc/shadow, it ignores local accounts that do not appear to belong to a "human" user (this includes accounts with nologin as their shell, among others). (It also ignores local human users above an arbitrary limit of 50, to avoid having a ridiculously long list.) However, there are several reasons why accountsservice might have a user account in its in-memory list, and one of those reasons is that it recently created the account itself. The accounts listed in its D-Bus API are the union of everything it has found from multiple sources. When accountsservice is deciding whether an account is local, it assumes that the only accounts that are local are the ones in its list of accounts from /etc/shadow, after filtering. Pseudocode: local = empty set interesting = empty set for account in /etc/shadow: if account appears human and number of accounts found so far < 50: local.add(account) interesting.add(account) for account in other sources: interesting.add(account) for account in interesting: account.LocalAccount = bool(account in local) return interesting I think this is a bug. It should look more like this pseudocode: local = empty set interesting = empty set for account in /etc/shadow: local.add(account) if account appears human and number of accounts found so far < 50: interesting.add(account) for account in other sources: interesting.add(account) for account in interesting: account.LocalAccount = bool(account in local) return interesting or maybe even: interesting = empty set for account in /etc/shadow: if account appears human and number of accounts found so far < 50: interesting.add(account) for account in other sources: interesting.add(account) for account in interesting: account.LocalAccount = (getspnam(account.UserName) != NULL) return interesting gnome-control-center is not exactly helping here, by not having a particularly clear indication of whether it thinks an account is local or remote, and using the same button for deleting a local account (which literally does delete the account) and removing a remote account from the cache (which just forgets about the account as being locally relevant, but does not attempt to delete it from LDAP or whatever remote accounts database it's using). This is not ideal, but I don't think it's RC for gnome-control-center. Meanwhile, gdm3 only lists accountsservice accounts (local or remote) in its GUI, but lets other accounts log in via "Not listed?". Because accountsservice wrongly thinks your account is remote, and you used gnome-control-center to remove the "remote" account from the cache of interesting accounts, gdm3 stopped listing it. However, it's still possible to log in with that account, because gdm3 doesn't check whether users' shells are listed in /etc/shells or not. (Should it? Other entry-point services don't, except indirectly by trying to run the user's shell and having nologin fail as a result.) smcv
Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login
Control: reassign -1 gnome-control-center,accountsservice Control: found -1 gnome-control-center 1:43.2-2 Control: found -1 accountsservice 22.08.8-1 (Quoting full bug report for accountsservice maintainers) On Wed, 01 Feb 2023 at 20:56:08 +0200, Timo Lindfors wrote: > Steps to reproduce: > 1) Run "gnome-control-center user-accounts" > 2) Click "Unlock..." > 3) Enter root password > 4) Click "Add User..." > 5) Enter "demo2" as Name and Username and click "Add". > 6) Click "Remove User..." > 7) Click "Delete" when prompted. > 8) Logout > 9) Select "Not listed?" and login as "demo2". Set the new password when > prompted. > 10) Hit the GUI key and type terminal, right click to access terminal > preferences > 11) Set the custom command in Unnamed/Command to /bin/bash > 12) Start terminal > > Expected results: > 9) Login fails since the user has been deleted > > Actual results: > 9) Login succeeds even though the user was deleted from the UI. > > More info: > > This issue is particularly scary since both the settings application > and the login screen do not show the user after it has been > deleted. This gives the user the impression that the deletion actually > succeeded. The prompt for "Remove User..." says "Are you sure you want to revoke remotely managed demo2's account?" which is unexpected: I didn't create this as a remotely managed user, I created it as a local user. This might indicate that gnome-control-center has got confused about the correct way to delete the account. Another clue that the wrong thing is happening is that I wasn't prompted for whether to delete the user's home directory and mail spool. Looking briefly at the gnome-control-center code, I think this indicates that act_user_is_local_account() is returning false, so instead of deleting a local user, gnome-control-center is telling accountsservice to "uncache" a remotely-managed (enterprise) user? I don't know what practical effect that has, but it doesn't sound like a true "delete" operation? This seems like at least partially an accountsservice bug: I would have expected that it would reject attempts to do enterprise-single-signon operations on a local Unix user. smcv
Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login
On Wed, 01 Feb 2023 at 20:56:08 +0200, Timo Lindfors wrote: > 6) Click "Remove User..." > 7) Click "Delete" when prompted. Do you happen to know what this actually does, behind the scenes? > This issue is particularly scary It's too late now, but in future, if you're reporting an otherwise undisclosed security vulnerability, please report it privately so that the information isn't immediately available to attackers. smcv
Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login
Package: gnome-control-center Version: 1:43.2-2 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: timo.lindf...@iki.fi, timo.lindf...@iki.fi, Debian Security Team Steps to reproduce: 1) Run "gnome-control-center user-accounts" 2) Click "Unlock..." 3) Enter root password 4) Click "Add User..." 5) Enter "demo2" as Name and Username and click "Add". 6) Click "Remove User..." 7) Click "Delete" when prompted. 8) Logout 9) Select "Not listed?" and login as "demo2". Set the new password when prompted. 10) Hit the GUI key and type terminal, right click to access terminal preferences 11) Set the custom command in Unnamed/Command to /bin/bash 12) Start terminal Expected results: 9) Login fails since the user has been deleted Actual results: 9) Login succeeds even though the user was deleted from the UI. More info: This issue is particularly scary since both the settings application and the login screen do not show the user after it has been deleted. This gives the user the impression that the deletion actually succeeded. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-control-center depends on: ii accountsservice 22.08.8-1+b1 ii apg 2.2.3.dfsg.1-5+b2 ii colord1.4.6-2.1 ii desktop-base 12.0.2 ii desktop-file-utils0.26-1 ii gnome-control-center-data 1:43.2-2 ii gnome-desktop3-data 43.1-1 ii gnome-settings-daemon 43.0-4 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-1+b1 ii libadwaita-1-01.2.1-2 ii libc6 2.36-8 ii libcairo2 1.16.0-7 ii libcolord-gtk4-1 0.3.0-3 ii libcolord21.4.6-2.1 ii libcups2 2.4.2-1+b2 ii libepoxy0 1.5.10-1 ii libfontconfig12.14.1-3 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.5-1 ii libgnome-bg-4-2 43.1-1 ii libgnome-bluetooth-ui-3.0-13 42.5-2 ii libgnome-desktop-4-2 43.1-1 ii libgnome-rr-4-2 43.1-1 ii libgnutls30 3.7.8-4 ii libgoa-1.0-0b 3.46.0-1 ii libgoa-backend-1.0-1 3.46.0-1 ii libgsound01.0.3-2 ii libgtk-3-03.24.36-2 ii libgtk-4-14.8.3+ds-1+b1 ii libgtop-2.0-112.40.0-2 ii libgudev-1.0-0237-2 ii libibus-1.0-5 1.5.27-4 ii libkrb5-3 1.20.1-1 ii libmalcontent-0-0 0.11.0-3 ii libmm-glib0 1.20.4-1 ii libnm01.40.10-1 ii libnma-gtk4-0 1.10.6-1 ii libpango-1.0-01.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-gobject-1-0 122-2 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse0 16.1+dfsg1-2+b1 ii libpwquality1 1.4.5-1+b1 ii libsecret-1-0 0.20.5-3 ii libsmbclient 2:4.17.5+dfsg-1 ii libsnapd-glib-2-1 1.63-4 ii libudisks2-0 2.9.4-4 ii libupower-glib3 0.99.20-2 ii libwacom9 2.5.0-1 ii libx11-6 2:1.8.3-3 ii libxi62:1.8-1+b1 ii libxml2 2.9.14+dfsg-1.1+b3 ii webp-pixbuf-loader0.0.5-5 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.6-5+b1 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.28.1-1 ii gnome-bluetooth-sendto42.5-2 ii gnome-online-accounts 3.46.0-1 ii gnome-remote-desktop 43.3-1 ii gnome-user-docs 43.0-1 ii gnome-user-share 43.0-1 ii iso-codes 4.12.0-1 ii libcanberra-pulse 0.30-10 ii libnss-myhostname 252.4-2 ii libspa-0.2-bluetooth 0.3.65-1 ii malcontent-gui0.11.0-3 ii network-manager-gnome 1.30.0-2 ii polkitd 122-2 ii power-profiles-daemon 0.12-1+b1 ii realmd0.17.1-1 ii rygel 0.42.0-2 ii rygel-tracker 0.42.0-2 ii system-config-printer-common 1.5.18-1 Versions of packages gnome-control-center suggests: ii gnome-software 43.3-1 pn gstreamer1.0-pulseaudio ii pkexec 122-2 ii x11-xserver-utils
