Hacker News new | ask | show | jobs
by realusername 776 days ago
I really don't think the app model makes any sense for a Linux desktop anyways.

You need this sandboxing on the phone not because of security but because the developer of the app is untrusted, that's the opposite of Gimp / Krita / VLC or whatever else is packaged where the author is trusted and the sources are available.

4 comments

On the contrary, giving Gimp/Krita/VLC root access to my computer makes no sense to me.

Do people think that distribution developers are hand combing through all those apps? Untrusted by default is more scalable.

> giving Gimp/Krita/VLC root access to my computer

Why would you give those apps root access?

nevermind root. The apps have unrestricted access to your filesystem under the same privileges as your user -- in other words, they have access to all your personal files and configurations and keys. Who needs root?
> nevermind root. The apps have unrestricted access to your filesystem under the same privileges as your user

Easy to get root anyway, just add an alias to sudo to .bashrc and whenever the user follows an online instruction guide into fixing something they'll get root privileges.

or overwrite LD_PRELOAD for the user

or replace the users desktop files and pretend to be another application (because you can overwrite /usr/share/applications launchers in .local/share/applications)

Wouldn't those attacks all require the user to have set up passwordless sudo?
You can change sudo into an alias that steals your sudo password and then does whatever else.

Not that it makes a huge difference in practice, IMO. The apps most users run (i.e. distro apps) are plenty trusty for normal threat models. Apps that run real untrusted code (web browser) have their own sandboxes. And people with more serious threat models can run qubes or tails or whatever

This is a fair point but orthogonal to the one I was responding to. In any case, a lot of Flatpak's sandbox can be overridden at build time. The sandbox will protect the user against bugs but not as much against a malicious developer.
the sandbox overriden need tobe explaining for the app tobe added to flathub, and yes, they need allow some sandbox breakage until every app support portals, or flathub isn't going to have any app
> Why would you give those apps root access?

You shouldn't but you install debs/rpms from the internet which get root permissions during install.

Not the apps though. The packaging system yes, but whatever scripts run as part of the installation of a package is the package maintainer's responsibility. Not trusting your distro's package maintainers means you don't trust anything on your computer.
Local privilege escalation.
As in, sudo? Again, why?
Accidental, not purposeful.

As in, any unrestricted process with user privileges on Linux can up to root through vulnerabilities in the kernel or other components. Namespaces, LSMs, and seccomp limit that exposure.

> giving Gimp/Krita/VLC root access to my computer

> unrestricted process with user privileges on Linux can up to root through vulnerabilities in the kernel or other components

Getting pwnd via vulnerabilities is very different from giving root access. You're arguing with a strawman, I'd rather not engage.

Trust is a part of security. "The developer is untrusted and may download a copy of all my emails if given access" is definitely a security / access control concern.
Then maybe it should not be accessible in the repository then if there's any doubt about the software.
There's always doubt about software. Even if it's your software, the compiler or the distribution site can be compromised. It's not a technical problem - it's like saying "you shouldn't interact with people if there's any doubt about them".

The solution is choosing an acceptable level of trust and putting safeguards like sandboxing where possible. (And ideally monitoring on the possible violations)

This is too one size fits all. It's either "every package is untrusted" so the repo is useless, or it's "there's too many people to keep track of the trust level of" which is insecure.

It's much harder to make a trust bet like that than, in principle, to make a local decision like "Hmm, why is the xz tool requesting access to the ssh port? That doesn't seem right"

What we need is something orthogonal to package managers, something like Firejail or bwrap.

In other words, sandboxing based on permissions, without loosing the advantages of having fine-grained control over dependencies.

Flatpak is a step forward in terms of sandboxing, but a step back in terms of dependency control.

That's not a sufficient level of trust. The author should basically never be trusted and it's extremely difficult to verify that the source of what's available is the same as what's in the binary that you downloaded.

Just look at the xz backdoor... "Author trusted"...

I will always prefer "trust the developers" Linux model to "trust the manufacturers" that you have on mobile.

Sandboxing just puts the problem one level higher and doesn't remove it.

Then on the subject of the xz backdoor, nothing is safe from that kind of attack.

Uh... No.

We are always going to have much greater confidence in the security of the base OS than the security of random apps in the ecosystem.

You named some great applications that have seen a lot of scrutiny... But what if someone installs a malicious gimp plugin, or wants to use a closed source app like discord? Your argument falls apart quickly.

> We are always going to have much greater confidence in the security of the base OS than the security of random apps in the ecosystem.

Where exactly is that true? Certainly not on mobile. There's a reason why I don't put anything sensitive on it...

And on Linux I'd say it's about the same for both.

For closed source apps I agree with that and something like snap/flatpack is maybe a better model for them.

On mobile, CalyxOS and GrapheneOS see a lot more attention than say, Breezy Weather.

On workstations, glibc and coreutils see a lot more attention than e.g. xonotic.