Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Linux Desktop Security

bjornpagen.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: State of Linux Desktop Security

#61

Post by infokiller »

mirimir wrote: post #10
throwaway888abc wrote: post #2

There is also Qubes for security sensitive work https://www.qubes-os.org/ https://www.whonix.org/ Still, I like the point/aim author is taking.

Right. Or where it matters less, VirtualBox or KVM. And where it matters more, hardware compartmentalization.

> And where it matters more, hardware compartmentalization.

With the caveat that you need to use secure air-gapped communication, and you probably want to use Qubes on each of the separate machines as well [1].

[1] https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...

Re: State of Linux Desktop Security

#62

Post by infokiller »

sprash wrote: post #39

People rarely run untrusted software on FOSS systems. If you can't trust your package manager and your distrobution you have all kinds of problems the least of which is sandboxing applications. The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account. The notion that every application must be 100% sandboxed is mostly security theater and will make your life wit…

If you define untrusted software as anything not coming from your distro's official package manager, many people run lots of untrusted software on their Linux systems. Think of PPAs (Debian/Ubuntu/etc), the AUR (Arch/Manjaro), and many other package managers (pip, conda, npm, cargo, etc.).

Re: State of Linux Desktop Security

#63

Post by RMPR »

JonAtkinson wrote: post #40
RMPR wrote: post #36

>Any app running under Xorg can see the contents of any other app runing under Xorg. It's one of the problems addressed by Wayland

Wayland remains very immature, and it still has significant shortcomings in hardware support. It's a beta-level technology at best, while Xorg has 20 years of stability behind it. It isn't responsible to suggest it as an alternative.

> Wayland remains very immature

Many people (me included) use Wayland as a daily driver, so I guess it's mature enough to be used, and I don't even use a DE with all the convenience, I use Sway, coming from i3, and everything I used is working fine, either with an alternative, or relying on XWayland.

>it still has significant shortcomings in hardware support

Apart from Nvidia (which is not that great with Xorg either) I don't know what you're referring to.

> It isn't responsible to suggest it as an alternative

Some mainstream distributions (e.g. Fedora) have defaulted to Wayland, are you calling the maintainers irresponsible?

Re: State of Linux Desktop Security

#64

Post by doteka »

user234683 wrote: post #26

More broadly, even in systems such as Windows, arbitrary programs have way too much access to the system, especially the filesystem. A lot of effort is put into patching exploits that allow for a program to gain root, yet this is largely irrelevant for desktop users [1]. If malware takes over system files, the operating system can just be reinstalled. The relevant threat is malware encrypting or stealing personal fil…

I’m not sure you’re aware but you basically described the way it works in the latest macOS. If an app wants to touch something in user folders, it has to ask for permission.

Re: State of Linux Desktop Security

#65

Post by tsimionescu »

lifty wrote: post #49
tsimionescu wrote: post #44

Earlier quoted context omitted.

While I think you are right to some extent, articles like the parent's are mostly aimed at people claiming 'Linux Desktop is actually better for grandma'. The reality is that grandma is going to be better protected while running Windows or MacOS or Chrome OS. If she's running Linux, she is wide open. Also, some of the most common practices on Linux that are claimed to be superior from a security standpoint are just b…

The external provided software repos are one thing I find superior on Linux, compared to macOS and Windows. It gives you an OS managed way to do updates to 3rd party providers, as opposed to each app shipping their own update code, many times running as a background daemon. On macOS, the situation for apps outside of the app store is a ghetto. Not sure about Windows as I don’t use it often, but I suspect it’s similar…

Sure, it has advantages, but it is less secure than downloading a binary, since you can check if the binary is downloading stuff off the internet or not, while the repo could be benign today, but malign tomorrow when the company hosting it gets bought, for example.

Also, from what I've seen, custom updaters are still the most common way of delivering updates for Linux outside the distribution-maintained official repo, as most people ship software for many distributions, and maintaining one repo per distribution quickly gets annoying. Ironically, this wouldn't be a problem on Windows or MacOS, if they decided to include a package manager with support for custom repos (the app stores allow side-loading, but do not allow custom upstream, as far as I know).

Re: State of Linux Desktop Security

#68

Post by sprash »

infokiller wrote: post #62
sprash wrote: post #39

People rarely run untrusted software on FOSS systems. If you can't trust your package manager and your distrobution you have all kinds of problems the least of which is sandboxing applications. The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account. The notion that every application must be 100% sandboxed is mostly security theater and will make your life wit…

If you define untrusted software as anything not coming from your distro's official package manager, many people run lots of untrusted software on their Linux systems. Think of PPAs (Debian/Ubuntu/etc), the AUR (Arch/Manjaro), and many other package managers (pip, conda, npm, cargo, etc.).

You have always the option to put programs that you don't trust into a jail. It just shouldn't be mandatory.

Besides, the only good way to solve that problem is namespaces as they are used in Plan9. Sadly Unix/Linux took the wrong turn at some point (probably with the introduction of sockets).

Re: State of Linux Desktop Security

#69

Post by viraptor »

nwmcsween wrote: post #28
viraptor wrote: post #13

Earlier quoted context omitted.

Forking then setting a policy in parent works though (if you don't need to spawn more workers). Or you can have a "worker spawner" process.

And that defeats a large portion of how programs work by first having root to bind to low ports, etc then forking a worker not to mention you have to restructure your program for seccomp vs ifdef for pledge. There are a bunch of ways of sandboxing on Linux but not many projects use it because implementing it is just painful, compared to pledge even external projects outside of openbsd will accept simple ifdef patches…

Fortunately socket activation is gaining support. The whole idea of having a privileged process just to bind can be skipped. But even without it, I'm not sure why it matters for seccomp - you bind then you apply the policy. Just like typically you first bind, then setuid.

Re: State of Linux Desktop Security

#70

Post by blaser-waffle »

throwaway888abc wrote: post #2

There is also Qubes for security sensitive work https://www.qubes-os.org/ https://www.whonix.org/ Still, I like the point/aim author is taking.

Is Qubes worthwhile if I'm doing anything more complicated than web browsing and lite scripting? (bash/perl, maybe some light python or flavor of js)
Post reply on HN