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

51–60 of 89 posts

Re: State of Linux Desktop Security

#51

Post by sprash »

lifty wrote: post #50
sprash wrote: post #48

Earlier quoted context omitted.

Yes, I run those programs in a separate Xorg session. If I need it on the same session I simply spin up a Xephyr window.

Sounds like a hassle. You might as well run it on a separate computer, at least you will be able to use them at the same time. I would prefer better app isolation so I can run everything with the same user, but still hold the apps accountable for what they are doing. OS’s have been designed when the computing paradigm was “computer as large as a building shared by 20 people that write their own software”. That paradi…

It is not a hassle because it is rare to run untrusted software on FOSS systems. Also spinning up a Xephyr window is trivial and not at all like "running it on a separate computer". Setting permissions for each and every installed application in a whitelist model you are proposing would be much more of a hassle. It is already a nightmare on Android where you wave away all kinds of access rights at the point of installing and you just don't care anymore because it becomes really annoying.

The solution to better security is not sandboxing. It is running only trusted application in the first place and making the implementation of those applications simple enough so that many people can understand the source code.

Re: State of Linux Desktop Security

#52

Post by sam_lowry_ »

dTal wrote: post #35

Perhaps what is broken is not our operating systems, but the notion that a computer program running on one's own computer can be an untrusted agent of a third party. I don't the tools in my collection to be isolated from each other, dangerous creatures in a computerized zoo. I want them to be composable elements of a cohesive whole. I want them to share data so promiscuously that is difficult to tell where one progra…

I will take this into my fortune file!

Re: State of Linux Desktop Security

#53

Post by tinus_hn »

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…

Many people just paste command lines they find on the internet which start with

    curl ... | bash

Re: State of Linux Desktop Security

#54

Post by infokiller »

AnthonyMouse wrote: post #4

> Windows and MacOS enforce signature checking on all binaries. This is not a meaningful security feature. If the signature has to be from the manufacturer then you can't so much as write your own shell script, which is useless. That is a cage, not a security measure. But if the user can sign their own binaries then the signature is the equivalent of the execute bit -- you have to tell the system something is executa…

Signatures are meaningful when the keys are more secure than the servers hosting the data.

If you download software from a hacked server that serves you malware, the signature check will fail. In contrast, the execute bit can be changed by anyone.

The problem is that you need to get the authentic public key of the software distributor to verify the signature. If an attacker is able to forge the public key, they can easily forge the signature and the signature check will succeed.

Re: State of Linux Desktop Security

#55

Post by arminiusreturns »

>Linux distros are behind on implementing modern binary exploit mitigations.

Compile from source, use only trusted package managers, and sandbox and compartmentalize when possible.

>Linux distros have no concept of sandboxing

They may be inadequate or need improving, but these concepts are there, if rarely used by default.

>Any app running under Xorg can see the contents of any other app runing under Xorg.

There are ways to prevent this without saying "Wayland".

>The only good sandoxing API provided by the Linux kernel is seccomp-bpf, and the only program that uses it is Google Chrome/Chromium.

The very link to the wikipedia entry for seccomp shows otherwise...

>Also a friendly reminder that Debian is always behind on CVEs, and I'm sure that most distros don't fare any better.

This is a good point, and one of the reasons I think that the future will belong to rolling release style distros with a faster CVE cycle.

Just the few things that stood out to me, not a piece by piece analysis.

Re: State of Linux Desktop Security

#56

Post by noobermin »

arminiusreturns wrote: post #55

>Linux distros are behind on implementing modern binary exploit mitigations. Compile from source, use only trusted package managers, and sandbox and compartmentalize when possible. >Linux distros have no concept of sandboxing They may be inadequate or need improving, but these concepts are there, if rarely used by default. >Any app running under Xorg can see the contents of any other app runing under Xorg. There are…

What mitigations exists for the Xorg apps?

Re: State of Linux Desktop Security

#57

Post by infokiller »

zenhack wrote: post #18

I'm dubious of some of these -- the code signing thing strikes me as not that compelling for reasons other comments have already pointed out. Others are very valid. But more than "how are we doing vs Apple and Microsoft?" I'd kinda prefer to set the bar a bit higher. Desktop operating systems (all of them, at least with actual users) are just completely architecturally backwards for the reality of our modern security…

I agree that Android app security model is much better than desktop Linux (of course, they had the privilege of designing a new system without backward compatibility concerns and after learning lessons from other systems).

The main issue with using that model for desktop Linux is that apps where not developed with this model in mine. So when an app wants to access your webcam, it tries to do it directly and doesn't ask the OS to grant permission. Similarly when accessing any files.

I guess it's possible in theory to trace any system calls the app makes and accordingly trigger permission requests to the user. Since that didn't happen, maybe it just breaks to many apps to be effective.

BTW, installed apps could create their own UID to isolate themselves, but most developers/distros don't bother doing it. I should not that I did see a significant improvement in running systemd services as separate users, but I rarely see it for user facing apps.

A better option than only using a separate UID is containerization, and things like docker, firejail, bubblewrap, etc, are useful here.

But Linux containers are not considered secure enough (at least compared to VMs). The real gold standard in terms of security is QubesOS, but you pay for that security in performance and ease of use.

Re: State of Linux Desktop Security

#58

Post by infokiller »

sprash wrote: post #46
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

Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks. The fact that nobody really uses them should tell you that the sandboxing craze and whitelisting is mostly if not completely security theater and hostile to the general workflow typical for Desktop applications. Wayland addresses none of thos…

> Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks.

One notable exception is OpenSSH, which uses the SECURITY extension with the -X flag (which is their recommended way to use X11 forwarding).

Re: State of Linux Desktop Security

#59

Post by sprash »

tinus_hn wrote: post #53
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…

Many people just paste command lines they find on the internet which start with curl ... | bash

And what do you want to do about it? Do you want to sandbox Bash? That would make Bash completely useless.

Re: State of Linux Desktop Security

#60

Post by infokiller »

dTal wrote: post #35

Perhaps what is broken is not our operating systems, but the notion that a computer program running on one's own computer can be an untrusted agent of a third party. I don't the tools in my collection to be isolated from each other, dangerous creatures in a computerized zoo. I want them to be composable elements of a cohesive whole. I want them to share data so promiscuously that is difficult to tell where one progra…

While I can appreciate your vision, that seems too detached from the current reality.

Software development is a highly distributed system with many human participants with different (and sometimes conflicting) goals and skills. And to make it effective, you almost always need to reuse software created by many other people that you don't know (which incidentally creates a huge opportunity for supply chain attacks).

In this reality, you get very little assurance about the authenticity and security of anything you use.

Post reply on HN