State of Linux Desktop Security • Hacker News Board

Re: State of Linux Desktop Security

#11

Post by twothamendment » Thu, Jun 18, 2020, 4:38 AM UTC

cwyers wrote: post #9

alcoholic_byte wrote: post #6

Well. The principle of Linux was and still is to give tools and have users use them. It gets out of the users way to use them. One can always use firejail or other sandboxing solutions to do that. Chrome itself is a security nightmare, always with the mic on and listening. Microsoft and Apple also have CVEs unattended. Binary checks before starting a program? Why I have a package-manager that does the checks. Untrust…

> The principle of Linux was and still is to give tools and have users use them. A circular saw is a tool, one without a handguard is a bad tool even if it cuts wood well.

I found that a 14" circular saw with the guard removed was a great tool. It demanded a lot of respect - much like some tools in Linux.

./run-saw --yes-without-the-guard

Re: State of Linux Desktop Security

#12

Post by nwmcsween » Thu, Jun 18, 2020, 4:41 AM UTC

Seccomp is painful, you need to fork a 'seccomp' fork as you cannot seccomp the parent and child to differing permissions, With pledge this is simple.

Re: State of Linux Desktop Security

#13

Post by viraptor » Thu, Jun 18, 2020, 5:11 AM UTC

nwmcsween wrote: post #12

Seccomp is painful, you need to fork a 'seccomp' fork as you cannot seccomp the parent and child to differing permissions, With pledge this is simple.

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.

Re: State of Linux Desktop Security

#14

Post by saagarjha » Thu, Jun 18, 2020, 5:27 AM UTC

> glibc's allocator is primitive compared to LLVM's Scudo allocator, which mitigates use-after-frees and heap overflows.

Ok, who actually uses Scudo (I've certainly never heard of it)?

Re: State of Linux Desktop Security

#15

Post by gizmo686 » Thu, Jun 18, 2020, 5:34 AM UTC

29athrowaway wrote: post #7

What about SELinux or AppArmor?

I made a post about that here [0].

I don't think anyone is seriously applying those to a desktop system.

They are both based on the Linux Security Module subsystem; which is just too low level to be effective at desktop security. Essentially, they suffer from the same problem as traditional UNIX permissions: no one cares that the attacker cannot access system files. The user's bank account is in their home directory.

[0] https://news.ycombinator.com/item?id=23155269

Re: State of Linux Desktop Security

#16

Post by craftinator » Thu, Jun 18, 2020, 5:43 AM UTC

bitbang wrote: post #8

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…

I'd rather shit Legos than have to deal with binary signature checking.

On Linux, just automate it.

Re: State of Linux Desktop Security

#17

Post by tkubacki » Thu, Jun 18, 2020, 5:47 AM UTC

"flatpak and snap are both security nightmares" and then link to flatpak article... Come on at least bother to explain... As far as I know - with all bad publicity snap has recently - it does isolate package and you don't give root to package maintainer.

Bold claims no arguments

Re: State of Linux Desktop Security

#18

Post by zenhack » Thu, Jun 18, 2020, 5:52 AM UTC

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 landscape, and what users need from their system. Protection boundaries are still mostly between different users. for most systems that's borderline useless, as there's only one user. Meanwhile every app runs with the full authority of the user and can do anything they can do.

Smartphones are a little better; Android equates "user" with "app" which is at least vaguely useful. But the permissions you end up with are still too coarse grained.

There are better designs out there. For example: web pages can ask the user for a file without getting access to everything the user owns (or at least in the case of Android, all of their files). Why can't native apps do this?

Re: State of Linux Desktop Security

#19

Post by j88439h84 » Thu, Jun 18, 2020, 5:53 AM UTC

What about firejail?

Re: State of Linux Desktop Security

#20

Post by j88439h84 » Thu, Jun 18, 2020, 5:56 AM UTC

cwyers wrote: post #9

alcoholic_byte wrote: post #6

Well. The principle of Linux was and still is to give tools and have users use them. It gets out of the users way to use them. One can always use firejail or other sandboxing solutions to do that. Chrome itself is a security nightmare, always with the mic on and listening. Microsoft and Apple also have CVEs unattended. Binary checks before starting a program? Why I have a package-manager that does the checks. Untrust…

> The principle of Linux was and still is to give tools and have users use them. A circular saw is a tool, one without a handguard is a bad tool even if it cuts wood well.

Extremely well said.