If the risks are so immense, surely we shouldn't be allowed root on our laptops either?

bornfreddy 3 days ago | parent | next [-]

Pssst, quiet, don't give them any ideas... :-/

codethief 3 days ago | parent | prev | next [-]

From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.

▲

jampekka 3 days ago | parent | next [-]

Android of course requires root for installing and configuring applications. It just grants the root automatically.

	▲	strcat 2 days ago \| parent \| next [-]
		No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
	▲	oneshtein 3 days ago \| parent \| prev [-]
		Developers cannot trust a random phone «owner».

▲

fsflover 3 days ago | parent | prev [-]

Have a look at https://qubes-os.org to understand why you're mistaken.

▲

codethief 2 days ago | parent [-]

I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.

	▲	fsflover 2 days ago \| parent [-]
		> so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root So if I don't use sudo then the problem with root is solved?

▲

subscribed 2 days ago | parent | prev | next [-]

And there's reason why normal windows / Linux laptops are less secure.

Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?

And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?)

I hope you're at least running your laptop with selinux in enforcing mode :)

▲

yellowapple 2 days ago | parent | next [-]

> Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?

The availability of application sandboxen and the availability of root access are two entirely separate security concerns.

▲

yupyupyups 2 days ago | parent [-]

Someone can correct me if I'm wrong.

If the GUI stack is vulnerable, then those sandboxes could be broken out of. The idea behind not allowing an app to access root is to remove the attack surface introduced by the GUI stack. An alternative interface to a GUI would be some physical connection (like usb-c). So accessing root exclusively via a console port or USB would be safer in theory.

This is true regardless if it's a phone or a PC.

Desktops are unfortunately waaaay behind something like GrapheneOS or iOS in terms of sandboxing. The closest in the desktop world is Qubes OS, but that's not a realistic alternative to normal OSes for the common user.

	▲	jampekka 2 days ago \| parent [-]
		Running GUI programs as root has been discouraged more or less always. Nowadays GUI programs that need root request it, via e.g. PolicyKit, for the specific operations it is needed. I very much don't want to have some external device to have root access to my computer. If iOS type sandboxing where I can't access most of the data at all is ahead, I'm glad to be behind.

▲

jampekka 2 days ago | parent | prev [-]

I'm willing to take the very slight chance of getting compromised in exchange for getting things done.

▲

paulhart 3 days ago | parent | prev | next [-]

That's a Chromebook, no?

	▲	jampekka 3 days ago \| parent [-]
		Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guide...

▲

ajjahs 3 days ago | parent | prev [-]

[dead]