Hacker News new | past | comments | ask | show | jobs | submit login

Thank you! Linux desktop is far from secure, even with all these suggested solutions. The lack of popularity by attackers means defenders and coders alike focus on mitigations based on assumptions or a small amount of historical data.

From a bad guy's perspective, they just need a foot in the door and move laterally if possible.

In my opinon, while all these hardening features are great, nothing beats behavioral detection and prevention. This isn't easy on linux to be honest, but a way for admins(power users?) To define rules like "a process tree with firefox as a parent is running unusual commands or processes" , more or less what is done with sysmon except with perhaps the audit subsystem would be of tremendous use. Assuming you can't prevent initial access or exploitation, what can be done to detect attacker activity on Linux Desktop?




It doesn’t have to be; desktop Linux users tend to behave.

Go installing random blobs and running scripts from people that download other scripts? Yes you’ll get owned, don’t do that. Even if all your friends are doing it don’t do that.


No,see that's your assumption I talked about. That's not a targeted attack for example, if someone is targeting you or your org, they will not wait for you to open a random malicious script somewhere.

Example: let's say you are not very technical or fairly new to Linux. You visit a hotel and their legitimate captive portal asks you to install a package with a download link which when installed allows secure access, most people in the category i described will install it. Or let's say you visit ubuntiforums or Linux questions a lot and you receive an email from them(you don't know email can be spoofed like 99% of people) about an emergency security advisory for some package,distros are working on a fix but here's a link to a patched package if you want to help test it's stability, good chance majority of users in the category I described would install that package since it came from a trusted source. And fyi, I just described two TTPs of the APT darkhotel: https://attack.mitre.org/groups/G0012/

My point is, if someone studies you well enough to know what you trust and don't trust, their attacks will tuned to work against you. There are many ways to get pwned and attackers need only one to work. Your expectation that everyone should know all the attack vectors well enough to defend themselves is impractical. Even seasoned pros will overlook verifying downloads with GPG here and therr for example.

This isn't just my opinion, you have to assume if targeted, they will at least get initial access.


It doesn't work that way. You're assuming. People are people, you can't assume "they'll behave". Let's use China or Russia who switched to Linux desktop for their operations, will their users be any less susceptible to social engineering just because they use linux? Look, what you have to understand is, even in the world of Linux Desktops it is a much bigger world than the echo chambers we're used to where the only other users are tech workers and enthusiasts.


You mean behave like the usual curl ... | sh advice that is so prevalent nowadays?


Disclaimer: I'm the author of Grapl[0], which aims to do what you're talking about. Normally I don't really comment on the product on HN, but you're describing Grapl's raison d'être.

So, audit is one subsystem people use. ebpf is another.

OSQuery[1] is a tool that'll make it pretty easy to hook into audit and collect things like process executions.

Once you have instrumentation you want to start writing those rules. This is where systems like ElasticSearch, Splunk, or in the case of my product, Grapl, come in.

What Grapl makes particularly easy, and what other systems make quite hard, is the type of detection you're talking about - process tree analysis, or generally any kind of analysis that spans many events/ entities. This is because Grapl will take the instrumentation output and generate a graph, which makes joins across the data quite efficient, and it exposes the graph via Python, so you can express pretty arbitrary logic. Other systems make joins quite painful and slow[2][3]

Grapl's not at the point where a power user could just get it up and running - though it will be very soon. I've written detection logic very much like what you're describing though[4].

Linux is actually doing fairly well here, in my opinion. OSX was probably the worst, but the ESF will change this. Windows, with Sysmon, is still probably the simplest and best solution for instrumentation (though ETW is pretty strong too).

[0]https://github.com/insanitybit/grapl [1]https://osquery.readthedocs.io/en/stable/

[2]https://docs.splunk.com/Documentation/Splunk/8.0.2/SearchTut... (ctrl + f 'In large production environments, it is possible that the subsearch in this example will timeout before it completes.')

[3]https://www.elastic.co/guide/en/elasticsearch/reference/curr...

[4] https://github.com/insanitybit/grapl-analyzers/blob/master/a... , https://github.com/insanitybit/grapl-analyzers/blob/master/a...


Very interesting, I hope to see your work mature.

Expensive EDRs already do this well. The UI,rules and having a place to put the data is hardest part imho. Linux makes things difficult because so many componets are by design reused extensively.

I will look into Grapl, thanks for sharing.


> From a bad guy's perspective, they just need a foot in the door and move laterally if possible.

How does the bad guy get a foot in the door?


> How does the bad guy get a foot in the door?

If you were using Ubuntu Linux in 2007-2008 you will remember the compiz/beryl craze. Everybody and their dog wanted the latest version of compiz.

Adding random repositories was not a problem if that got you the latest version of compiz/beryl.

Until a guy, one of the maintainers of a popular repository, tricked everybody: in the install scripts he added code to change the desktop background to an image with a text reading: don't add random repositories from the internet.

Think about all the random repositories and PPAs that people add to their systems without thinking. That is an example of how you get a foot in the door.


> Think about all the random repositories and PPAs that people add to their systems without thinking.

This doesn't seem like a "desktop Linux security" problem. It seems like a "some users do dumb things" problem. You can't fix that with an OS. But I can "fix" it easily by not adding random repositories and PPAs.


Lots of security issues are fixed not by “fixing” them but by adding mitigations which include user approval, surfacing otherwise hidden activity, and other crutches. At the end of the day it is an automated system and must do things without the human in the loop, so the best you can do is make “the loop” visible to the user.


> user approval

Adding a repository/PPA does require user approval. You can't do sudo without knowing you're doing it.

> surfacing otherwise hidden activity

Yes, and Linux gives you plenty of tools to do that, like, say, "ps aux" and "top" (or the many GUI equivalents in various desktop environments).

> At the end of the day it is an automated system

Remember we're talking about desktops here, not servers. Desktops are not "automated" in any relevant sense for this discussion.


Agree that isn't a great example. Linux package repos are still far in advance of the mish mash of stores and direct install that is Windows and MacOS.

Programs like Thunderbird and every Gnome program with an embedded web browser are a bit problem. It's really hard to prevent random web stuff from happening on your box, and I don't want anything except a fully patched Chrome/Chromium or Firefox talking http(s) to anything unless it is audited, isolated and constrained to do a small number of tasks.

Office suites and file viewers are ripe for exploits. I'd argue that open office has an essentially unlimited supply. PDF readers ... Ugh. Even simple image tools have occasional oopses.

Confining the small Linux tools that do simple things is actually a good match for containment technology; where it fails is big complex GUIs like office suites, or tools that need broad file system access and network comms.

If Linux had any standards for the file dialogue it would be much simpler to retrofit access controls. Even Android is so far in advance of desktop Linux it is hard to see the catch-up happen. I almost can't believe that desktop linuxes still don't support running Android apps.


> Programs like Thunderbird and every Gnome program with an embedded web browser are a bit problem.

Yes, which is why I don't use any of them.

> It's really hard to prevent random web stuff from happening on your box

No, it isn't. You simply don't run programs that aren't trustworthy. If you want to know what network activity your programs are doing, that's what "netstat" is for.

> Office suites and file viewers are ripe for exploits.

Yes, which is why I don't use them except in particular cases (open source PDF viewers are generally OK, and for the times when I'm forced to open an office document, LibreOffice has good defaults for not running embedded macros or resolving embedded links).

> I almost can't believe that desktop linuxes still don't support running Android apps.

These people seem to be taking a stab at it:

https://anbox.io/

In any case, the divergence here is due to Android, not desktop Linux; Google deliberately made Android enough of a "not Linux" to make its apps incompatible with desktop Linux.


I would like to have per-application egress control on linux without containerising everything myself or writing baroque filtering that is undebuggable. I shouldn't need to trust every line of code in some massive package just to run it safely -- and I shouldn't have to tcpdump it to see what it is doing on the network.


This doesn't seem like a "desktop Linux security" problem.

It is a desktop Linux security problem, because people will want to install applications that are not available in a distribution. So, you should provide a mechanism to let them do that relatively securely.


I once discovered a botnet running on my Ubuntu system. I always assumed a PPA the culprit. The ip addresses were gazprom, some stuff in China, a ton of others, etc - too long ago to remember details. I also remember when I first started with Arch, which at that time had unsigned packages.

Edit: comment truncated by sleeping aid. I've gone dumb, but also remember the router suffering too, even after a hard reset, westell, I think.


I also remember when I first started with Arch, which at that time had unsigned packages.

Very much at the urging of Arch maintainers not to, people are using package managers to install stuff from AUR, where literally anyone can upload PKGBUILDs.

Another easy vector (for developers) are language package managers. E.g. Rust's Cargo runs build scripts (small Rust programs for configuration) for many crates, unsandboxed.


Using malformed PDFs, documents, mp3s, etc. Exploiting browser, ssh, php, mysql, mail server vulnerabilities, etc, etc. By no means a trivial task, but the attack surface is large enough that sec bugs keep being introduced.

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

https://www.cvedetails.com/product/36/Debian-Debian-Linux.ht...

https://www.cvedetails.com/product/20550/Canonical-Ubuntu-Li...

https://www.cvedetails.com/product/79/Redhat-Enterprise-Linu...


Depends on the bad guy. Social engineering is the best way on desktops. And this is what I meant by assumptions, on windows I can tell you phishing and removable drives are the easiest way. On Linux desktop it simply isn't targeted enough to be confident which attack vectors are common.

But you're missing the point, there will always be vulnerabilities. Even if everything is written in Rust, logical vulns exist, default config issues will exist (mongodb and internet exposure for example) and even the smartest people can be phished. Even with a yubikey,if I can trick you into opening a link that will have you download and open a file that will execute code on your machine, I don't need your login because I have your session cookies and I can reverse tunnel traffic through your IP. And I may not even care about that, maybe I just want your ssh private key and I will be on my way.


> Social engineering is the best way on desktops.

Nobody uses my Linux desktop/laptop computers but me, and I have no reason to tell anyone else anything about them, so I don't. So I'm not vulnerable to this attack vector.

> if I can trick you into opening a link that will have you download and open a file that will execute code on your machine

I never click on links unless I know their source. So I'm not vulnerable to this attack vector either.

If all that is wrong with the desktop Linux security model is "some users do dumb things", then that's not fixable by any OS. And even with that said, Linux is much better at containing the damage from doing dumb things than, say, Windows.


I guarantee you, you will fall for a clever phish. You can't outsmart a good spearphish. You are wrong when you think stupidity is the vuln, the vuln is basic human psychology. But even if you're right, it's not like Linux desktop is made only for people like you right? It wouldn't be "some people are dumb" it would be "almost all people are dumb" even if being dumb was the issue.


> I guarantee you, you will fall for a clever phish.

You can guarantee no such thing. Not getting caught by phishing just isn't that hard. It requires a little self-discipline, yes. So do most worthwhile things.

> It wouldn't be "some people are dumb" it would be "almost all people are dumb" even if being dumb was the issue.

That's still not an OS issue. No amount of clever programming will help if people are that determined to do something dumb.


That's still not an OS issue. No amount of clever programming will help if people are that determined to do something dumb.

And yet, a malicious iOS cannot typically take over the OS, other applications, or exfiltrate data from other applications. Sure, someone's bank account can be fished. But systems like iOS show that it is possible to protect users against a large numbers of attacks.

One of the goals of an OS is to provide meaningful isolation boundaries. This is why we have a separation between ring 0 and 3, isolation of process address spaces, a separation between UID 0 and UID > 0. There is no reason why we should not introduce new forms of isolation invented after the 70ies.


> a malicious iOS cannot typically take over the OS, other applications, or exfiltrate data from other applications

Neither can a malicious Linux application.


This is nonsense.

A malicious Linux application can exfiltrate all the data in your home directory. Taking over the OS is not hard either, just run a keystroke logger or put a rogue sudo in the user's path.

Of course, this does not apply if the application is properly sandboxed, which is sadly not the default on Linux yet.


You ever run a pip install? Maybe an apt-get install?


> You ever run a pip install?

On my regular desktop, not of anything that wasn't Python code I had written myself.

In development containers, yes, sometimes I've installed third-party Python programs to test them (and of course in Python it's easy to read the source code since what you install is the source code), but that's isolated from my regular desktop.

> Maybe an apt-get install?

Never of anything that wasn't from my distro's signed package repository.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: