[TheDong]

The article was about two issues that combine to make a single local-privilege-escalation, so the PAM thing isn't a separate exploit chain, it's just part of getting local root in this vulnerability.

What the parent poster meant is that you first need a way to run arbitrary code before local privilege escalation matters, so the exploit chain has to include _something_ that gets you local code execution.

I tend to agree with the parent poster, for most modern single-user linux devices, local privilege escalation means almost nothing.

Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too.

If you have a local privilege escalation too, you still get my passwords, bitcoin wallet, etc, and also uh... you can persist yourself better by injecting malware into sshd or something or modifying my package manager? idk, seems like it's about the same.

[simoncion]

> ...for most modern single-user linux devices, local privilege escalation means almost nothing.

I haven't actually looked at the numbers, but I strongly suspect that it's true that the overwhelming majority of single-user Linux devices out there are Android devices. If that's true, then it's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access.

[akdev1l]

Android is not a single user system. Every app, every service basically everything gets its own user.

Applications have different user IDs and different SELinux contexts.

Android security is tight

[simoncion]

Android is nearly always a single user system in the sense that TheDong was using. Look at the context a little further down in the guy's comment:

> Like, I'm the only user on my laptop. If you get arbitrary code execution as my user, you can log my keystrokes, steal my passwords and browser sessions, steal my bitcoin wallet, and persist reasonably well.... and once you've stolen my password via say keylogging me typing `sudo`, you now have root too.

In this context, "single user system" means either "single human using the system", or "one human physically sat in front of the system's 'console' at one time". It's in contrast with systems that have multiple human users logged in and using the system simultaneously. So, nearly 100% of "single user systems" of this type will have software running under different "user" accounts on the system, but still meet the definition, because those accounts are actually "machine" or "service" accounts.

I do think that this overload of the terminology is bogus and confusing. It should be called something like "single seat system", but here we are.

> Android security is tight

Yep. That's what I said: "[I]t's my understanding that Android does bother to fairly properly sandbox programs from each other... so an escalation to root would actually be a significant gain in access."

[akdev1l]

The context is that on a traditional Linux laptop/desktop you are in fact running everything as one user.

Firefox, the desktop environment, your password manager and even `sudo` are traditionally all running as your own user.

This is not true in Android whatsoever.

Being multi-seat or not has little security implications - most traditional Linux systems can handle multi-seat but they’re still limited in security by running everything as a single user

And no nearly all 100% of Linux systems do not run proper multi-user configurations because none of the most popular distributions ship like that. Not in the context of desktop usage anyway.

Servers do use multi-user configuration but that’s not what we’re talking about here

[simoncion]

> The context is that on a traditional Linux laptop/desktop you are in fact running everything as one user.

Um. Have you ever run 'ps aux', guy? At minimum you're running everything as two users (root and your user account), and probably three to twenty more, depending on what you have installed. I know that on my desktop system

  ps axo user | sort -u | grep -v USER | wc -l

returns 12. Even back in the late 1990s/early 2000s, the default method of operation for Linux systems was to use multiple machine accounts.

> And no nearly all 100% of Linux systems do not run proper multi-user configurations because none of the most popular distributions ship like that. Not in the context of desktop usage anyway.

In addition to my commentary above, see: <https://help.ubuntu.com/stable/ubuntu-help/user-add.html.en>

Most Linux systems don't run every single program as a separate Linux user. That doesn't mean that those systems are "in fact running everything as one user".

[akdev1l]

are you linking to the fact that “useradd” exists to prove your point…?

Lmfaoooo

I’m assuming you have actually never ran a linux on your desktop. Lmaooooo.

Yeah sure init runs as root, and maybe you have background services that run as some other user.

BUT YOUR ACTUAL DESKTOP SESSION RUNS AS ONE USER. THIS INCLUDES YOUR BROWSER, YOUR PASSWORD MANAGER AND ALL YOUR OTHER SHIT!

https://paste.centos.org/view/f8e5ec76

so multi-user much secure

You know being a know-it-all only really works if you know what you are talking about.

Feel free to dig into the code of gnome-session if you don’t believe me.

[DaSHacka]

Does Android use Udisks? I assumed it did not, due to the difference in architecture over most traditional GNU/Linux desktop systems

[simoncion]

I have no idea if Android uses udisks. It has been something like a decade since I last looked at 'ps' output on an Android machine, so any information on the topic I might have had has faded away with time.

[worthless-trash]

Some services dont run as the same user logging into the laptop.