Turns out that removing nobody is not so crazy after all

Well, not really, but you know.

6 Likes

Ohh interesting

Haven’t read the entire thing but is this Ubuntu specific or anyone using GDM?

I’m not sure - it sounds pretty Ubuntu-centric, but then the fixes may be needed on any system with the older software versions.

I’ll read more into it later but looks like it might abuse GNOME for privilege escalation. I don’t think accounts service is Ubuntu specific and gdm doing its initial setup bit seems to be the key so likely effects other systems running GNOME but not 100%

If it does I can see about removing that initial setup from GDM with a patch temporarily

1 Like

I’ll test this when I get home to see if it works on EOS

1 Like

I’m going to assume that it’s fixed in the upstream GNOME versions - Ubuntu is frozen pool and runs older (often unfixed) versions.

Possibly, but if nobody knew about it could very likely still be upstream so want to make sure. If it does I can hack something together to stop it

I suspect that it is an Ubuntu-only item - because Ubuntu does not have a root account (at all). Thus the gdm capability to create an ‘original’ privileged user - which may not even exist in other gdm instances…

Of course - I only pretend to know what I’m talking about :grin: I try to use logic, and that sometimes fails - and in the meantime I’ll steer clear of Gnome!

1 Like

I just skimmed it but it doesn’t create the root user but a separate user with sudoer privledges which is bad still

The initial setup part is in other GDM as its a GNOME thing for initial user setup on OEM systems

1 Like

2 Likes

That’s why I think it is an Ubuntu-only thing - most other setups have a root user at some point - Ubuntu never does. The sudoer privilege is the ONLY root capabilities on an Ubuntu system. Of course, you can use the sudo power to ACT like root if desired - but a search for root will find you nothing…

1 Like

I’ll read it more when I’m home you may be correct but I want to be 100% sure.

It turns out that Ubuntu uses a modified version of accountsservice that includes some extra code that doesn’t exist in the upstream version maintained by freedesktop. Ubuntu’s patch adds a function named is_in_pam_environment, which looks for a file named .pam_environment in the user’s home directory and reads it. The denial of service vulnerability works by making .pam_environment a symlink to /dev/zero.

5 Likes

Ah, good ol’ Ubuntu, modifying software and introducing vulnerabilities…

4 Likes

Fair enough - but you might need to fire up a VM with Ubuntu on it to see. No root entry in /etc/shadow or /etc/passwd for instance…

Thus I can’t see any reason for that capability on any other version of gdm - but you don’t know that till you try it out. Things are sometimes done without a reason :grin:

Cool so it is just Canonical being stupid and changing things for no reason :joy: saves me work then if it depends on Ubuntu jacking up Account Services

3 Likes

@anon3337769 saved me the worry, just Canonical breaking things as usual lol

This shouldn’t be an issue with upstream Account Services

3 Likes

That’s pretty much what I suspected - for the reasons as stated above. They had a reason - but occasionally the law of unintended consequences…

Here’s what the first line of /etc/shadow looks like on an Ubuntu 20.04 (though mine is XFCE and lightdm, so safe enough):

freebird@nest:~$ sudo cat /etc/shadow
root:!:18454:0:99999:7:::

It all hangs together - but it leads to unexpected places! :grin:

4 Likes