9 ms·

Desktop Linux is insecure

72 points by bjornpagen 3y ago

theamk 3y ago
tl/dr: author wants sandboxing everywhere
Llamamoe 3y ago
I have been thinking about this recently in fact. I hate the way Android collects telemetry, but any process and likely most websites I use on Linux can access my clipboard, filesystem, list of programs, OS monitoring tools, even log my keypresses if they want to. The question is what can I do about this?
- bittercynic 3y ago
  This is scary news to me. I usually assume Firefox and Chromium on linux do a reasonable job of balancing security and usability. Is the situation really that bad?
  - quesera 3y ago
    It is not that bad. A browser sandbox escape would be red-alert news and fixed within hours.
  - ziml77 3y ago
    Unless there is an exploit that lets a webpage escape the sandbox, they will have access to none of those things listed without permission
  - kaba0 3y ago
    An npm install is much more dangerous than the browser, imo. But the fact remains, there is basically no usable security on linux desktops and it is a shame (especially when built on top the exact same core we have very secure systems)
- autoexec 3y ago
  Can't you just lock your browser down to prevent that? Don't allow JavaScript to run in your browser (or at the very least don't allow it by default) and suddenly 99% of the tricks websites use to gather that kind of data about your system stop working.
- lionkor 3y ago
  all processes, yes, but no websites
- susanthenerd 3y ago
  > and likely most websites I use on Linux can access my clipboard That is totally false. Any good web browser is asking for permission first.
hacker_homie 3y ago
Yeah we know don’t let the normies in or we will have to fix it. And I don’t I don’t want to buy a Mac.
xcdzvyn 3y ago
Linux absolutely has a plethora of software one can use to improve security - AppArmor, Flatpak, Snap, and whatnot; the "all or nothing" approach the author mentioned is also not inherent to Linux, just a common setup people use. You can absolutely limit user access to a subset of superuser commands. The problem is nobody cares. Linux users don't care, and even the users of sandboxed OSes don't care. I'm more irritated by macOS constantly popping up with "iTerm2 wants to access your Documents folder" than comforted. Some distros implemented e.g. AppArmor to generally positive reviews, but Ubuntu's transition to Snaps has been seen very very negatively. Wayland "features" some protections too - apps can't access the global clipboard, or move themselves, screen-record, whatever. And nobody likes it! Because the inconvenience far outweighs the benefits. Overwhelmingly I think the "problem" is that Linux users don't really want, or need, this protection macOS/ChromeOS offers. An aside: Windows has sandboxing? Where?
- cerved 3y ago
  Windows has UAC, so you run things like root all the time, it's great
  - stop50 3y ago
    Its equivalent to polkit
    - phendrenad2 3y ago
      Polkit is a very badly-designed, poorly-executed imitation of UAC. UAC is an operating-system-level system that heuristically detects when an executable is acting as an installer, and prompts the user with a Yes/No prompt (you can see screenshots online). This even works if you're running a terminal command. Terminal command needs administrator access? You get a blocking, modal dialog from the system that forces you to click Yes or No. That's very powerful. Polkit is a component for controlling system-wide privileges in Unix-like operating systems, the manpage is less than 2 pages.
      - 3y ago
toastal 3y ago
Could & should things be better by default? Sure, but in practice, all of the proprietary software I don't trust but need to run for work all have a web app that is sandboxed in the browser which is generally good enough for my threat models. Hilarious though that the author thinks is Nix is “imcomprehensible”. You can even do things like nix shell nixpkgs#proprietary-crap and ditch the application after using it to do one thing.
ChoHag 3y ago
[dead]
NoZebra120vClip 3y ago
Author is totally correct to promote ChromeOS as a modern, sandboxed, low-attack-surface alternative. Unfortunately, Achilles heels of ChromeOS are in the usual places: browser extensions and integrations that can access any web page you view, or do anything they want with your Google account, which can wreak havoc for people with a lot of stuff in there. Now what I will say for consumer Linux distributions is that it's eminently possible to easily reduce your attack service in a few ways: judicious configuration, and strip down all unnecessary software packages! I was sysadmin for a long time before I realized that I was a glutton for apps and I had a tendency to consume them and hoard them without regard for what I really needed to run on a day-to-day basis. I would install software, try it once, and finding it boring, I abandoned it, but it was all still installed. So I began perusing my list of installed software and I'd just remove anything that was obviously unnecessary. I'd even remove stuff that I didn't know what it did, just to see if something broke, but things rarely broke! My position was validated! If you remove unneeded software, you will automatically reduce the number of network services running too. That thing you installed probably started up a server, started listening on local and global addresses, and may have even poked holes in the firewall for itself. Do you need that? Can someone make a lateral move from your pwned router into your desktop machine through your neglected services? Get rid of them. Linux affords much more latitude to a security-minded administrator than Windows. Windows will not let you turn stuff off without causing breakage or it will just gratuitously come back in an update and be turned back on. The Linux philosophy is beyond that nonsense. Yes, Linux out of the box, or Linux in the hands of an ordinary end-user, it's insecure. But it has more potential than Windows. For a while, I pondered whether I could outsource my personal, home IT work to an MSP. But MSPs don't do personal networks, they do B2B. I think Geek Squad is possibly missing a bet here. Not that I would let Geek Squad into my Linux homelab, but it's a thought.
- autoexec 3y ago
  I imagine handing all your network traffic to literally any third party that cares only about profit is going to be a security nightmare.
- pjmlp 3y ago
  It is a well known fact that many Linux software will break with proper LinuxSE enforcement, just like Windows software not designed to be tamed by group policies.
corn13read2 3y ago
I'd like to talk, this is something we want.
- 29athrowaway 3y ago
  https://en.wikipedia.org/wiki/AppArmor https://en.wikipedia.org/wiki/AppArmor https://en.wikipedia.org/wiki/Security-Enhanced_Linux https://en.wikipedia.org/wiki/Security-Enhanced_Linux
- bjornpagen 3y ago
  Email me at contactatbjornpagen.com!
biglost 3y ago
This technologies basically do what Docker does, but without the overhead of a virtualized Linux kernel There’s really no reason why a system upgrade requires root privileges,
semiquaver 3y ago
Tough to keep reading after seeing this kind of misunderstanding > There are a whole bible of strategies that ChromeOS implements to keep Chrome in it’s own little world. Among the strategies involve cgroups, namespacing, seccomp, etc… This technologies basically do what Docker does, but without the overhead of a virtualized Linux kernel Docker doesn’t have a virtualized Linux kernel, it uses the same technologies mentioned directly on the existing kernel. > Also, Linux desktop software has a very all-or-nothing approach to permissions. Root, or user. I wonder why more systems don’t make use of Linux capabilities [1]. Technically root hasn’t been necessary for years; it’s just a convenient shorthand for “all capabilities”. Lots of things that needlessly run as root could instead be granted a much more limited set of capability xattrs instead by the package manager and consented to by the user. Using root in 2023 is lazy. [1] https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html
- bjornpagen 3y ago
  fixed #1, thanks
qzio 3y ago
Qubes-os is considered pretty secure. https://www.qubes-os.org/ https://www.qubes-os.org/
exabrial 3y ago
We use the hell out of systemd sandboxing for just running _everything_. Why fire up an extraordinary docker container when you can just create a container on the fly?
Timber-6539 3y ago
Am tired of seeing low effort posts about why Linux is insecure.
thoi234u34234 3y ago
[flagged]
- garbagecoder 3y ago
  what do you suggest then?
- johnfernow 3y ago
  C was created over 50 years ago. I wonder if the creator ever imagined that it would become and remain the language used to develop the kernel that powers the majority of the world's servers and phones half a century later (though Rust is just starting to be used in the Linux kernel.) Even C++ is 38 years old. And these are just the languages; the systems our current OSs are inspired from were designed without much security in mind: understandably so, considering Unix was also created over half a century ago, long before the Internet. GNU was created nearly 40 years ago, and even Linux released over 30 years ago, only 2 years after the world wide web was invented, so cyber attacks were not very common. At least with iOS and Android we've been able to have a better permission model than most desktop OSs (e.g. applications have to ask permission to use the camera), as well as better sandboxing (one application can't just read files from other applications: users explicitly have to share things from one app to another, and can revoke permissions at any time.) But I agree with you that they're ultimately built with primitive languages and questionable design decisions. That's not a criticism of anyone who designed those systems and languages: the fact that they're widely used half a century later shows how incredibly good they were for the time! But a lot has changed in 50+ years (and especially the last 20-30 years with the Internet), and we've learned a lot. We do get new languages, though I feel like we still have much to improve: the fact that Electron is so widely used for desktop applications (even ones that aren't web apps) shows how far we have to go for languages and their frameworks. But at least there are people trying to make better programming languages and frameworks. Unfortunately the outlook on OSs seems grimmer. There are some hobbyist OSs that are extremely impressive, but I'm not sure any of them look likely to replace the OSs we use for servers, desktops, phones or other devices. With all we know today, we could design and build an OS that is far more secure than what we have today. But the costs of doing so would be enormous, so I understand why no organization has taken on this task.
deleted 3y ago
[deleted]
29athrowaway 3y ago
There's Security Enhanced Linux (SELinux) maintained by the NSA, AppArmor and others. If security is what you want, you can have it.
- commandersaki 3y ago
  Ah, security theatre.
  - PrimeMcFly 3y ago
    Hardly.
amstan 3y ago
Honestly I feel less secure with sandboxes Android apps that I do on desktop Linux. On Linux I use my distro's curated repository (ex to install cozy, an ebook reader, or yt-dlp), I don't care that it has access to the rest of my system, the bonus point is that I can have access to its source code. On Android, the first app I see has "In-app purchases" and will probably spy on me. Yes... I agree I guess, on Android (therefore ChromeOS) app stores I definitelly want sandboxing because it's a very adversarial relationship between the users and the apps. Unfortunatelly that means you need to get into sandboxes, throw stuff in VMs and all the other things that will make performance and efficiency suck. I miss the time where my computer ran only software I controlled and it wasn't a free for all where everyone wants to run random code (Javascript from websites is a big one here). All the Specter/Rowhammer stuff is only because you're sometimes running untrusted code. Why do people need to be running untrusted code all the time? /me goes back in the cave
- yathaid 3y ago
  Just stop with this nonsense. This is such a foolish opinion that is bandied about from a "I know exactly what apps I run, sandboxing is for those noobs" mindset. Did you compile them yourselves? Did you compile the compiler? Let's just accept the fact that Linux comes from a place of "if you run a program you are responsible for what it does". This is contrary to modern users expectations of "just because I run a program it shouldnt be able to siphon all my data", largely driven by mobile apps and their ecosystem. If I autocomplete an ls command on my Mac's terminal it will warn me that iTerm is trying to access the specified folder. There is nothing like that on popular distros. The whole security landscape needs to be re-thought. Maybe someone who knows more than me can talk about bring features from more restricted Linux variants to a more broad audience.
  - jolmg 3y ago
    He's just bringing a valid point. Despite the lack of isolation between pieces of software, I too feel more confident about what's running on my Linux distros. That's not to say that "sandboxing is for noobs", but it's an interesting point. It's like how people in very rural areas can feel perfectly safe not locking doors and stuff, sleeping outside, etc., while that would be extremely foolish to do in the middle of certain cities, in certain neighborhoods. Different environments, different dangers, and I think it's fine to enjoy the benefits of a safer environment. Safety in this case is not provided by physical distance between homes but by curation of software done by nonprofit groups and selection of nearly only open source software with easy building of packages and tracking of changes in the source. > Did you compile them yourselves? Did you compile the compiler? There's no such thing as perfect security, and I think you know that. If you think your compiler may be compromised, there's stuff you could do, you just have to evaluate where the paranoia starts and stop before then.
Syonyk 3y ago
> It’s interesting to consider a Linux distribution that fixes these problems. I’ve thought a little bit about a secure linux desktop. But alas, what a waste of time that would be, right? It's called QubesOS. https://www.qubes-os.org/ https://www.qubes-os.org/ It's, if not an operating system directly, then a meta-operating-system and set of tools to allow you to easily interopreate a range of siloed VMs on top of a stripped Xen hypervisor. You can easily create, destroy, and use VMs, which can either be fully standalone, fully disposable (no disk state persists past the reboot), or, in the usual configuration, have a persistent home directory and template-based ephemeral root directory. Perks of that, you can update the template VM (via some reasonably thought out methods) and update all the software in the derived VMs as well. I've been using it as my primary desktop OS now for... oh, two years and change, perhaps? It's a bit like a virus, in a way - you install it on some random test machine, get a feel for it, and then install it on more machines, and it just kind of spreads around your network until you realize you've been working in Qubes for some while now and it's fine. The security model is basically, "Anything in a VM can be assumed to access anything else in that VM." So you silo things off, and if you're doing anything with unknown data (random PDFs, perhaps), you open it in a disposable VM (and there are some neat "render safe" capabilities that will then provide, back in your trusted VM, an image based version of a PDF file minus any bonus capabilities it might have come with). So you silo things. For instance, I do most of my "casual web browsing" in a disposable VM and I reboot that regularly. A full compromise of that browser stack gets you... the other tabs I have open, and perhaps a random file or two I downloaded. It doesn't get you anything of interest, as I also don't log into core accounts in that browser (I have another VM for core web activities that doesn't visit random sites). The main downside is no GPU acceleration of anything (framebuffer only), but it's somewhat less limiting than I'd assumed, and most of my machines maintain a dual boot of Ubuntu for anything GPU intensive, though I honestly use it a lot less than I'd assumed. And while it sounds like it would be resource intensive, and it can be, it's worth trying if you have less RAM than you might think. My "daily driver laptop" is a 2C/4T 5th Gen i7, with 16GB RAM. Gutless wonder, and I didn't expect much out of Qubes on it, but it actually works just fine (though I admit I'm not nearly as hard on computers as I used to be in terms of what I expect out of them). Clipboards are mentioned, and Qubes neatly solves that too, because you have separate keyboard shortcuts to move clipboard contents around - it's not hard to copy/paste between VMs (or move files between them), but "root in a VM" only gets you things pasted into that VM (unless you pop Xen and migrate to dom0, at which point it's rather game over, but... theoretically, that's a harder exploit chain than getting out of a browser). Also, as far as browser go, disable your Javascript JIT engine. No, I did not say "Disable Javascript." I said, "Disable your Javascript JIT engine." There are ways to do it on most browsers, and in exchange for slightly reduced daily performance and slaughtered Javascript benchmark performance, you remove an awful lot of complex attack surface in the browsers. My problem with containers and sandboxes is that they rely an awful lot (entirely?) on the Linux kernel not being able to be exploited, and my general assumption for years now is that a local root exploit is worth about $0, because they're reasonably common and easy to find. It's not exactly true, but it's closer to true than not, so I assume any arbitrary code running on my machines, if it so desires, can compromise the kernel. Sandboxing and containers are convenient to prevent well behaved application deployments from interfering with each other, but they're not sufficient against potentially malicious applications. It's a pessimistic view, but the last decade of computer security is pretty clear that the pessimists a decade ago were far, far too optimistic. Anyway, long post, short summary, "We probably shouldn't have put computers in everything."
pid-1 3y ago
Android is another example of OS that gets sandboxing right, I think (though not a Desktop OS). Anyway, that's also something I've been thinking lately after distro hoping for about 6 years... My average Linux install isn't particularly more secure than Windows. I'm mindlessly sudoing my way through stuff all the time. Clearly there is a Linux malware market to be explored.
- bediger4000 3y ago
  Where is that market?
its-summertime 3y ago
Flatpak: but it does stop someone installing a keylogger from a ffx exploit Systemd: $ # I use silverblue btw $ THINGS='Protect|Restrict|Capability|Lock|SystemCallFilter|Private|MemoryDeny|ReadWritePaths' $ AT='/usr/lib/systemd/system' $ grep -ilE "^($THINGS)" "$AT"/*.service | wc -l 64 $ grep -ilE '^Exec' "$AT"/*.service | wc -l 292 its a bit more than "No Linux distribution actually seriously uses them very much" and it provides a standard solution to "Meanwhile, developers don’t know the contexts in which their software is being run, and need to release portable programs. Developers therefore can’t assume what permissions their program will need with the rest of the system." "and it certainly isn’t as comprehensive as ChromeOS’s minijail." Kinda disagree. - - - Lot of words, no citations for those words. - - - Worth noting that, even among secure options there are points where there is slack: Android uses a uid/gid per app [auid], but chromeos doesn't [cuid] [auid]: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Users.md#int-uid https://android.googlesource.com/platform/frameworks/base/+/... [cuid]: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master/profiles/base/accounts/README.md https://chromium.googlesource.com/chromiumos/overlays/eclass...
stop50 3y ago
LD_PRELOAD is not an keylogger. Its an LD_PRELOAD is an Equivalent of an DLL hijack. To be save from this /home and /tmp are mounted as noexec to prevent all of these attacks. Libraries that contain executable code (i haven't found one that doesn't have at least a byte) require the executable bit, which is disabled with noexec.
zorrolovsky 3y ago
The overarching assumption of this article is that OS sandboxing is a 'must requirement'. I would challenge the author to explain why is the extra layer of sandboxing a must requirement. Do we know the size of the problem? As in... how many known websites run malicious scripts with real intent to do harm, and how many sites achieve that goal?. Do we know how many users got hacked because the lack of sandboxing in linux when doing typical web browsing? My view is that the article blows the problem out of proportion. Security relies to a great extent on user behaviour. User A visits known domains only, and opens emails from known senders only. They only share card and personal details with known and trusted parties. They only install the strictly necessary apps and from known devs only. User B visits any site regardless of domain. He shares email, phone number and card data at the earliest chance (ie when trying to buy illegal drugs from a clearnet shady store). He installs dozens of apps, often from unknown parties. Regardless of OS, browser and other context, user A is going to be safe most of the time and it's very rare that they in serious trouble. User B is an accident waiting to happen... If the above is true, maybe we don't need a technical solution like OS sandboxing. It would be more effective to create a standard for all browsers where the first screen you see is a big message saying: "Welcome to your 3 second online tutorial: Visit known websites where possible. Don't share your real personal details unless strictly necessary. Share details with known and trusted parties only. In case of doubt, don't trust the other party."
- erik_seaberg 3y ago
  Being careful sort of works, until the New York Times serves malvertising from an ad network: https://news.ycombinator.com/item?id=11296252 https://news.ycombinator.com/item?id=11296252
  - autoexec 3y ago
    "being careful" in my view includes blocking ads, reducing unnecessary remote connections to servers and not running unnecessary code. You can't avoid everything, but I think you can get by pretty well being careful. That does mean being more careful about doing things most people don't consider very risky though.
deleted 3y ago
[deleted]
ranger207 3y ago
I mean, it's about your threat model isn't it? The way I think of it, there's basically three ways for someone to break into my computer: remote code execution with no external preparation (as might be caused by ssh exposed to the internet with a common username and password), installing malicious programs, or opening malicious files that exploit buffer overflows or whatever. The first way might be protected by a sandbox or might not: if it is ssh that's pwned, presumably in a sandboxed environment you'd have given ssh all the permissions anyway, right? The second way is far less common a vulnerability on a desktop Linux system than on other OSes, including Android, because 99% of packages people are going to want to use on their desktop are going through the distro maintainers, which isn't a perfect process but seems to be pretty good. Contrast that to Android where malware gets through the Play Store all the time. iPhone seems to be about as good as Linux in this regard though. I'm not totally sure that sandboxing would help in this regard either. If someone exploited my PDF reader it'd probably have access to all my other PDFs wouldn't they? However if someone exploited my video player they wouldn't, and in either case they probably wouldn't have access to my browser, so yeah sandboxing would help there. But also included in the threat model is what you want to protect. Obviously bank passwords, tax information, etc, but I also want to protect my privacy in general, and right now there's no OS that's as privacy preserving as Linux. Furthermore, I don't trust sandboxing implementations in proprietary OSes from protecting my privacy either: they might say they protect my data against malicious apps trying to steal my stuff, but then if the OS itself tracks my location, search history, files, etc, sandboxing doesn't do much good, does it?
seba_dos1 3y ago
And yet it's the one I trust the most. Weird, isn't it?
fmajid 3y ago
Qubes offers this level of protection, but it’s not very popular and the virtualization imposes quite a lot of overhead.
joshspankit 3y ago
I feel like there’s a significant cultural shift that has gotten us here: For the most part we no longer share computers. We used to be constantly confronted with poor security practices: someone else accessing a file they shouldn’t, or installing some piece of software that took over a system function as a prank, or just miseducation leading to a critical config problem. I don’t know who set the wheels in motion first (though I suspect it was game makers) but we now have complete sovereignty over our devices and therefore only really think about security against internet intruders. Imo this leads to a much more abstracted and relaxed security mindset overall (including in the minds of the devs).
jillesvangurp 3y ago
The misconception here is that most of the valuable stuff actually lives inside the browser. That's where users access their email, banking information, use password managers, etc. Breaking out of the sandbox is a relatively low priority goal for hackers looking to compromise browsers. Which is why this is much less of an issue than the author assumes. Browsers have to be safe regardless of whether they are sand boxed. Which is why browsers use sand boxing technology inside the browser. Sand boxing your browser is relatively low value in terms of security benefits. This is less true on mobile because people use lots of apps there. And if you have some game implemented by a twelve year old and somebody hacks it and then installs whatever on the phone, that is a big issue. So Google and Apple spent a lot of time fixing that on mobile and then applied the same level of standards to their desktop operating systems. MS has of course over the years had their fair share of issues like that so they've gotten a lot better at this as well. Server side linux is pretty secure out of the box. Pretty much the whole internet runs on Linux at this point. Mostly servers only run one process that matters; which is whatever they are serving. Or a bunch of dockerized processes in some cases. Which are indeed sand boxed. Desktop Linux is server side linux with some extra stuff. Not a very homogeneous target to hack because there are lots of different software packages that people use in different combinations and versions. And the baseline security of Linux is of course not horrible like it used to be with Microsoft. And of course things like snap and flatpak actually do use some sandboxing. So, use that if it makes you feel good. Of course that sandboxing isn't perfect as I'm sure people will be itching to point out. But the problem that addresses is pretty minor to begin with. And there is of course a certain amount of resistance against using either of those with some people. So, not much of a problem and it's been kind of solved anyway.
nubinetwork 3y ago
Sounds like OP wants to run qubes. How cute. I wish them luck, because it also has "escape" vulnerabilities.
weare138 3y ago
As a long time Linux enthusiast and engineer this needs to be said and it's been overlooked for way too long. We need to figure out how to move past some of the traditional UNIX ways of doing things like apps keeping plaintext passwords in 'hidden' dotfiles. Even simple things would go a long way like making it straight forward to install packages from distro repositories in userspace. Every time you install a desktop app via the package system you're rolling the dice by giving the package root access. In fact that should be the default behavior for installing the vast majority of Linux apps. If an app doesn't legitimately need root access for anything we shouldn't grant it to begin with. Don't get me wrong Linux distros do a great job at maintaining security overall but these projects are massive now and in the age of supply chain attacks and hostile nation-state actors all it will take is one package to slip through to cause a major security incident. The Solarwinds hack was the proverbial canary in the coalmine. If it can happen to them it can happen to anyone. It's not a matter of if now but when.
nathants 3y ago
little snitch seems to be the correct approach. almost every compromise that isn’t target will attempt odd looking network connections. we need more little snitch like things, including for filesystem access. we also need the ability to run little snitch in paranoid mode, where the approvals happen on a separate device, sign each message with a key not on the primary device, and the validation is baked deeply and irrevocably into the kernel. smartphone face up on desk left of keyboard would work well for a second device. linux lsm seems to work[1], and building the kernel is easy locally[2] or on cloud[3]. hopefully we see more and better use of lsm and custom kernels. we all should want our most trusted public key baked irrevocably into the kernel. personalized linux is the next frontier! 1. https://github.com/nathants/mighty-snitch https://github.com/nathants/mighty-snitch 2. https://github.com/nathants/mighty-snitch/blob/master/kernel/arch/PKGBUILD https://github.com/nathants/mighty-snitch/blob/master/kernel... 3. https://github.com/nathants/mighty-snitch/blob/master/kernel/alpine/build.sh https://github.com/nathants/mighty-snitch/blob/master/kernel...

72 points by bjornpagen 3y ago

tl/dr: author wants sandboxing everywhere

I have been thinking about this recently in fact. I hate the way Android collects telemetry, but any process and likely most websites I use on Linux can access my clipboard, filesystem, list of programs, OS monitoring tools, even log my keypresses if they want to. The question is what can I do about this?

bittercynic 3y ago
This is scary news to me. I usually assume Firefox and Chromium on linux do a reasonable job of balancing security and usability. Is the situation really that bad?
- quesera 3y ago
  It is not that bad. A browser sandbox escape would be red-alert news and fixed within hours.
- ziml77 3y ago
  Unless there is an exploit that lets a webpage escape the sandbox, they will have access to none of those things listed without permission
- kaba0 3y ago
  An npm install is much more dangerous than the browser, imo. But the fact remains, there is basically no usable security on linux desktops and it is a shame (especially when built on top the exact same core we have very secure systems)
autoexec 3y ago
Can't you just lock your browser down to prevent that? Don't allow JavaScript to run in your browser (or at the very least don't allow it by default) and suddenly 99% of the tricks websites use to gather that kind of data about your system stop working.
lionkor 3y ago
all processes, yes, but no websites
susanthenerd 3y ago
> and likely most websites I use on Linux can access my clipboard That is totally false. Any good web browser is asking for permission first.

hacker_homie 3y ago

Yeah we know don’t let the normies in or we will have to fix it. And I don’t I don’t want to buy a Mac.

xcdzvyn 3y ago

Linux absolutely has a plethora of software one can use to improve security - AppArmor, Flatpak, Snap, and whatnot; the "all or nothing" approach the author mentioned is also not inherent to Linux, just a common setup people use. You can absolutely limit user access to a subset of superuser commands. The problem is nobody cares. Linux users don't care, and even the users of sandboxed OSes don't care. I'm more irritated by macOS constantly popping up with "iTerm2 wants to access your Documents folder" than comforted. Some distros implemented e.g. AppArmor to generally positive reviews, but Ubuntu's transition to Snaps has been seen very very negatively. Wayland "features" some protections too - apps can't access the global clipboard, or move themselves, screen-record, whatever. And nobody likes it! Because the inconvenience far outweighs the benefits. Overwhelmingly I think the "problem" is that Linux users don't really want, or need, this protection macOS/ChromeOS offers. An aside: Windows has sandboxing? Where?

cerved 3y ago
Windows has UAC, so you run things like root all the time, it's great
- stop50 3y ago
  Its equivalent to polkit
  - phendrenad2 3y ago
    Polkit is a very badly-designed, poorly-executed imitation of UAC. UAC is an operating-system-level system that heuristically detects when an executable is acting as an installer, and prompts the user with a Yes/No prompt (you can see screenshots online). This even works if you're running a terminal command. Terminal command needs administrator access? You get a blocking, modal dialog from the system that forces you to click Yes or No. That's very powerful. Polkit is a component for controlling system-wide privileges in Unix-like operating systems, the manpage is less than 2 pages.
    - 3y ago

toastal 3y ago

Could & should things be better by default? Sure, but in practice, all of the proprietary software I don't trust but need to run for work all have a web app that is sandboxed in the browser which is generally good enough for my threat models. Hilarious though that the author thinks is Nix is “imcomprehensible”. You can even do things like nix shell nixpkgs#proprietary-crap and ditch the application after using it to do one thing.

ChoHag 3y ago

[dead]

NoZebra120vClip 3y ago

Author is totally correct to promote ChromeOS as a modern, sandboxed, low-attack-surface alternative. Unfortunately, Achilles heels of ChromeOS are in the usual places: browser extensions and integrations that can access any web page you view, or do anything they want with your Google account, which can wreak havoc for people with a lot of stuff in there. Now what I will say for consumer Linux distributions is that it's eminently possible to easily reduce your attack service in a few ways: judicious configuration, and strip down all unnecessary software packages! I was sysadmin for a long time before I realized that I was a glutton for apps and I had a tendency to consume them and hoard them without regard for what I really needed to run on a day-to-day basis. I would install software, try it once, and finding it boring, I abandoned it, but it was all still installed. So I began perusing my list of installed software and I'd just remove anything that was obviously unnecessary. I'd even remove stuff that I didn't know what it did, just to see if something broke, but things rarely broke! My position was validated! If you remove unneeded software, you will automatically reduce the number of network services running too. That thing you installed probably started up a server, started listening on local and global addresses, and may have even poked holes in the firewall for itself. Do you need that? Can someone make a lateral move from your pwned router into your desktop machine through your neglected services? Get rid of them. Linux affords much more latitude to a security-minded administrator than Windows. Windows will not let you turn stuff off without causing breakage or it will just gratuitously come back in an update and be turned back on. The Linux philosophy is beyond that nonsense. Yes, Linux out of the box, or Linux in the hands of an ordinary end-user, it's insecure. But it has more potential than Windows. For a while, I pondered whether I could outsource my personal, home IT work to an MSP. But MSPs don't do personal networks, they do B2B. I think Geek Squad is possibly missing a bet here. Not that I would let Geek Squad into my Linux homelab, but it's a thought.

autoexec 3y ago
I imagine handing all your network traffic to literally any third party that cares only about profit is going to be a security nightmare.
pjmlp 3y ago
It is a well known fact that many Linux software will break with proper LinuxSE enforcement, just like Windows software not designed to be tamed by group policies.

corn13read2 3y ago

I'd like to talk, this is something we want.

29athrowaway 3y ago
https://en.wikipedia.org/wiki/AppArmor https://en.wikipedia.org/wiki/AppArmor https://en.wikipedia.org/wiki/Security-Enhanced_Linux https://en.wikipedia.org/wiki/Security-Enhanced_Linux
bjornpagen 3y ago
Email me at contactatbjornpagen.com!

biglost 3y ago

This technologies basically do what Docker does, but without the overhead of a virtualized Linux kernel There’s really no reason why a system upgrade requires root privileges,

semiquaver 3y ago

Tough to keep reading after seeing this kind of misunderstanding > There are a whole bible of strategies that ChromeOS implements to keep Chrome in it’s own little world. Among the strategies involve cgroups, namespacing, seccomp, etc… This technologies basically do what Docker does, but without the overhead of a virtualized Linux kernel Docker doesn’t have a virtualized Linux kernel, it uses the same technologies mentioned directly on the existing kernel. > Also, Linux desktop software has a very all-or-nothing approach to permissions. Root, or user. I wonder why more systems don’t make use of Linux capabilities [1]. Technically root hasn’t been necessary for years; it’s just a convenient shorthand for “all capabilities”. Lots of things that needlessly run as root could instead be granted a much more limited set of capability xattrs instead by the package manager and consented to by the user. Using root in 2023 is lazy. [1] https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html

bjornpagen 3y ago
fixed #1, thanks

qzio 3y ago

Qubes-os is considered pretty secure. https://www.qubes-os.org/ https://www.qubes-os.org/

exabrial 3y ago

We use the hell out of systemd sandboxing for just running _everything_. Why fire up an extraordinary docker container when you can just create a container on the fly?

Timber-6539 3y ago

Am tired of seeing low effort posts about why Linux is insecure.

thoi234u34234 3y ago

[flagged]

garbagecoder 3y ago
what do you suggest then?
johnfernow 3y ago
C was created over 50 years ago. I wonder if the creator ever imagined that it would become and remain the language used to develop the kernel that powers the majority of the world's servers and phones half a century later (though Rust is just starting to be used in the Linux kernel.) Even C++ is 38 years old. And these are just the languages; the systems our current OSs are inspired from were designed without much security in mind: understandably so, considering Unix was also created over half a century ago, long before the Internet. GNU was created nearly 40 years ago, and even Linux released over 30 years ago, only 2 years after the world wide web was invented, so cyber attacks were not very common. At least with iOS and Android we've been able to have a better permission model than most desktop OSs (e.g. applications have to ask permission to use the camera), as well as better sandboxing (one application can't just read files from other applications: users explicitly have to share things from one app to another, and can revoke permissions at any time.) But I agree with you that they're ultimately built with primitive languages and questionable design decisions. That's not a criticism of anyone who designed those systems and languages: the fact that they're widely used half a century later shows how incredibly good they were for the time! But a lot has changed in 50+ years (and especially the last 20-30 years with the Internet), and we've learned a lot. We do get new languages, though I feel like we still have much to improve: the fact that Electron is so widely used for desktop applications (even ones that aren't web apps) shows how far we have to go for languages and their frameworks. But at least there are people trying to make better programming languages and frameworks. Unfortunately the outlook on OSs seems grimmer. There are some hobbyist OSs that are extremely impressive, but I'm not sure any of them look likely to replace the OSs we use for servers, desktops, phones or other devices. With all we know today, we could design and build an OS that is far more secure than what we have today. But the costs of doing so would be enormous, so I understand why no organization has taken on this task.

deleted 3y ago

[deleted]

29athrowaway 3y ago

There's Security Enhanced Linux (SELinux) maintained by the NSA, AppArmor and others. If security is what you want, you can have it.

commandersaki 3y ago
Ah, security theatre.
- PrimeMcFly 3y ago
  Hardly.

amstan 3y ago

Honestly I feel less secure with sandboxes Android apps that I do on desktop Linux. On Linux I use my distro's curated repository (ex to install cozy, an ebook reader, or yt-dlp), I don't care that it has access to the rest of my system, the bonus point is that I can have access to its source code. On Android, the first app I see has "In-app purchases" and will probably spy on me. Yes... I agree I guess, on Android (therefore ChromeOS) app stores I definitelly want sandboxing because it's a very adversarial relationship between the users and the apps. Unfortunatelly that means you need to get into sandboxes, throw stuff in VMs and all the other things that will make performance and efficiency suck. I miss the time where my computer ran only software I controlled and it wasn't a free for all where everyone wants to run random code (Javascript from websites is a big one here). All the Specter/Rowhammer stuff is only because you're sometimes running untrusted code. Why do people need to be running untrusted code all the time? /me goes back in the cave

yathaid 3y ago
Just stop with this nonsense. This is such a foolish opinion that is bandied about from a "I know exactly what apps I run, sandboxing is for those noobs" mindset. Did you compile them yourselves? Did you compile the compiler? Let's just accept the fact that Linux comes from a place of "if you run a program you are responsible for what it does". This is contrary to modern users expectations of "just because I run a program it shouldnt be able to siphon all my data", largely driven by mobile apps and their ecosystem. If I autocomplete an ls command on my Mac's terminal it will warn me that iTerm is trying to access the specified folder. There is nothing like that on popular distros. The whole security landscape needs to be re-thought. Maybe someone who knows more than me can talk about bring features from more restricted Linux variants to a more broad audience.
- jolmg 3y ago
  He's just bringing a valid point. Despite the lack of isolation between pieces of software, I too feel more confident about what's running on my Linux distros. That's not to say that "sandboxing is for noobs", but it's an interesting point. It's like how people in very rural areas can feel perfectly safe not locking doors and stuff, sleeping outside, etc., while that would be extremely foolish to do in the middle of certain cities, in certain neighborhoods. Different environments, different dangers, and I think it's fine to enjoy the benefits of a safer environment. Safety in this case is not provided by physical distance between homes but by curation of software done by nonprofit groups and selection of nearly only open source software with easy building of packages and tracking of changes in the source. > Did you compile them yourselves? Did you compile the compiler? There's no such thing as perfect security, and I think you know that. If you think your compiler may be compromised, there's stuff you could do, you just have to evaluate where the paranoia starts and stop before then.

Syonyk 3y ago

> It’s interesting to consider a Linux distribution that fixes these problems. I’ve thought a little bit about a secure linux desktop. But alas, what a waste of time that would be, right? It's called QubesOS. https://www.qubes-os.org/ https://www.qubes-os.org/ It's, if not an operating system directly, then a meta-operating-system and set of tools to allow you to easily interopreate a range of siloed VMs on top of a stripped Xen hypervisor. You can easily create, destroy, and use VMs, which can either be fully standalone, fully disposable (no disk state persists past the reboot), or, in the usual configuration, have a persistent home directory and template-based ephemeral root directory. Perks of that, you can update the template VM (via some reasonably thought out methods) and update all the software in the derived VMs as well. I've been using it as my primary desktop OS now for... oh, two years and change, perhaps? It's a bit like a virus, in a way - you install it on some random test machine, get a feel for it, and then install it on more machines, and it just kind of spreads around your network until you realize you've been working in Qubes for some while now and it's fine. The security model is basically, "Anything in a VM can be assumed to access anything else in that VM." So you silo things off, and if you're doing anything with unknown data (random PDFs, perhaps), you open it in a disposable VM (and there are some neat "render safe" capabilities that will then provide, back in your trusted VM, an image based version of a PDF file minus any bonus capabilities it might have come with). So you silo things. For instance, I do most of my "casual web browsing" in a disposable VM and I reboot that regularly. A full compromise of that browser stack gets you... the other tabs I have open, and perhaps a random file or two I downloaded. It doesn't get you anything of interest, as I also don't log into core accounts in that browser (I have another VM for core web activities that doesn't visit random sites). The main downside is no GPU acceleration of anything (framebuffer only), but it's somewhat less limiting than I'd assumed, and most of my machines maintain a dual boot of Ubuntu for anything GPU intensive, though I honestly use it a lot less than I'd assumed. And while it sounds like it would be resource intensive, and it can be, it's worth trying if you have less RAM than you might think. My "daily driver laptop" is a 2C/4T 5th Gen i7, with 16GB RAM. Gutless wonder, and I didn't expect much out of Qubes on it, but it actually works just fine (though I admit I'm not nearly as hard on computers as I used to be in terms of what I expect out of them). Clipboards are mentioned, and Qubes neatly solves that too, because you have separate keyboard shortcuts to move clipboard contents around - it's not hard to copy/paste between VMs (or move files between them), but "root in a VM" only gets you things pasted into that VM (unless you pop Xen and migrate to dom0, at which point it's rather game over, but... theoretically, that's a harder exploit chain than getting out of a browser). Also, as far as browser go, disable your Javascript JIT engine. No, I did not say "Disable Javascript." I said, "Disable your Javascript JIT engine." There are ways to do it on most browsers, and in exchange for slightly reduced daily performance and slaughtered Javascript benchmark performance, you remove an awful lot of complex attack surface in the browsers. My problem with containers and sandboxes is that they rely an awful lot (entirely?) on the Linux kernel not being able to be exploited, and my general assumption for years now is that a local root exploit is worth about $0, because they're reasonably common and easy to find. It's not exactly true, but it's closer to true than not, so I assume any arbitrary code running on my machines, if it so desires, can compromise the kernel. Sandboxing and containers are convenient to prevent well behaved application deployments from interfering with each other, but they're not sufficient against potentially malicious applications. It's a pessimistic view, but the last decade of computer security is pretty clear that the pessimists a decade ago were far, far too optimistic. Anyway, long post, short summary, "We probably shouldn't have put computers in everything."

pid-1 3y ago

Android is another example of OS that gets sandboxing right, I think (though not a Desktop OS). Anyway, that's also something I've been thinking lately after distro hoping for about 6 years... My average Linux install isn't particularly more secure than Windows. I'm mindlessly sudoing my way through stuff all the time. Clearly there is a Linux malware market to be explored.

bediger4000 3y ago
Where is that market?

its-summertime 3y ago

Flatpak: but it does stop someone installing a keylogger from a ffx exploit Systemd: $ # I use silverblue btw $ THINGS='Protect|Restrict|Capability|Lock|SystemCallFilter|Private|MemoryDeny|ReadWritePaths' $ AT='/usr/lib/systemd/system' $ grep -ilE "^($THINGS)" "$AT"/*.service | wc -l 64 $ grep -ilE '^Exec' "$AT"/*.service | wc -l 292 its a bit more than "No Linux distribution actually seriously uses them very much" and it provides a standard solution to "Meanwhile, developers don’t know the contexts in which their software is being run, and need to release portable programs. Developers therefore can’t assume what permissions their program will need with the rest of the system." "and it certainly isn’t as comprehensive as ChromeOS’s minijail." Kinda disagree. - - - Lot of words, no citations for those words. - - - Worth noting that, even among secure options there are points where there is slack: Android uses a uid/gid per app [auid], but chromeos doesn't [cuid] [auid]: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Users.md#int-uid https://android.googlesource.com/platform/frameworks/base/+/... [cuid]: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master/profiles/base/accounts/README.md https://chromium.googlesource.com/chromiumos/overlays/eclass...

stop50 3y ago

LD_PRELOAD is not an keylogger. Its an LD_PRELOAD is an Equivalent of an DLL hijack. To be save from this /home and /tmp are mounted as noexec to prevent all of these attacks. Libraries that contain executable code (i haven't found one that doesn't have at least a byte) require the executable bit, which is disabled with noexec.

zorrolovsky 3y ago

The overarching assumption of this article is that OS sandboxing is a 'must requirement'. I would challenge the author to explain why is the extra layer of sandboxing a must requirement. Do we know the size of the problem? As in... how many known websites run malicious scripts with real intent to do harm, and how many sites achieve that goal?. Do we know how many users got hacked because the lack of sandboxing in linux when doing typical web browsing? My view is that the article blows the problem out of proportion. Security relies to a great extent on user behaviour. User A visits known domains only, and opens emails from known senders only. They only share card and personal details with known and trusted parties. They only install the strictly necessary apps and from known devs only. User B visits any site regardless of domain. He shares email, phone number and card data at the earliest chance (ie when trying to buy illegal drugs from a clearnet shady store). He installs dozens of apps, often from unknown parties. Regardless of OS, browser and other context, user A is going to be safe most of the time and it's very rare that they in serious trouble. User B is an accident waiting to happen... If the above is true, maybe we don't need a technical solution like OS sandboxing. It would be more effective to create a standard for all browsers where the first screen you see is a big message saying: "Welcome to your 3 second online tutorial: Visit known websites where possible. Don't share your real personal details unless strictly necessary. Share details with known and trusted parties only. In case of doubt, don't trust the other party."

erik_seaberg 3y ago
Being careful sort of works, until the New York Times serves malvertising from an ad network: https://news.ycombinator.com/item?id=11296252 https://news.ycombinator.com/item?id=11296252
- autoexec 3y ago
  "being careful" in my view includes blocking ads, reducing unnecessary remote connections to servers and not running unnecessary code. You can't avoid everything, but I think you can get by pretty well being careful. That does mean being more careful about doing things most people don't consider very risky though.

deleted 3y ago

[deleted]

ranger207 3y ago

I mean, it's about your threat model isn't it? The way I think of it, there's basically three ways for someone to break into my computer: remote code execution with no external preparation (as might be caused by ssh exposed to the internet with a common username and password), installing malicious programs, or opening malicious files that exploit buffer overflows or whatever. The first way might be protected by a sandbox or might not: if it is ssh that's pwned, presumably in a sandboxed environment you'd have given ssh all the permissions anyway, right? The second way is far less common a vulnerability on a desktop Linux system than on other OSes, including Android, because 99% of packages people are going to want to use on their desktop are going through the distro maintainers, which isn't a perfect process but seems to be pretty good. Contrast that to Android where malware gets through the Play Store all the time. iPhone seems to be about as good as Linux in this regard though. I'm not totally sure that sandboxing would help in this regard either. If someone exploited my PDF reader it'd probably have access to all my other PDFs wouldn't they? However if someone exploited my video player they wouldn't, and in either case they probably wouldn't have access to my browser, so yeah sandboxing would help there. But also included in the threat model is what you want to protect. Obviously bank passwords, tax information, etc, but I also want to protect my privacy in general, and right now there's no OS that's as privacy preserving as Linux. Furthermore, I don't trust sandboxing implementations in proprietary OSes from protecting my privacy either: they might say they protect my data against malicious apps trying to steal my stuff, but then if the OS itself tracks my location, search history, files, etc, sandboxing doesn't do much good, does it?

seba_dos1 3y ago

And yet it's the one I trust the most. Weird, isn't it?

fmajid 3y ago

Qubes offers this level of protection, but it’s not very popular and the virtualization imposes quite a lot of overhead.

joshspankit 3y ago

I feel like there’s a significant cultural shift that has gotten us here: For the most part we no longer share computers. We used to be constantly confronted with poor security practices: someone else accessing a file they shouldn’t, or installing some piece of software that took over a system function as a prank, or just miseducation leading to a critical config problem. I don’t know who set the wheels in motion first (though I suspect it was game makers) but we now have complete sovereignty over our devices and therefore only really think about security against internet intruders. Imo this leads to a much more abstracted and relaxed security mindset overall (including in the minds of the devs).

jillesvangurp 3y ago

The misconception here is that most of the valuable stuff actually lives inside the browser. That's where users access their email, banking information, use password managers, etc. Breaking out of the sandbox is a relatively low priority goal for hackers looking to compromise browsers. Which is why this is much less of an issue than the author assumes. Browsers have to be safe regardless of whether they are sand boxed. Which is why browsers use sand boxing technology inside the browser. Sand boxing your browser is relatively low value in terms of security benefits. This is less true on mobile because people use lots of apps there. And if you have some game implemented by a twelve year old and somebody hacks it and then installs whatever on the phone, that is a big issue. So Google and Apple spent a lot of time fixing that on mobile and then applied the same level of standards to their desktop operating systems. MS has of course over the years had their fair share of issues like that so they've gotten a lot better at this as well. Server side linux is pretty secure out of the box. Pretty much the whole internet runs on Linux at this point. Mostly servers only run one process that matters; which is whatever they are serving. Or a bunch of dockerized processes in some cases. Which are indeed sand boxed. Desktop Linux is server side linux with some extra stuff. Not a very homogeneous target to hack because there are lots of different software packages that people use in different combinations and versions. And the baseline security of Linux is of course not horrible like it used to be with Microsoft. And of course things like snap and flatpak actually do use some sandboxing. So, use that if it makes you feel good. Of course that sandboxing isn't perfect as I'm sure people will be itching to point out. But the problem that addresses is pretty minor to begin with. And there is of course a certain amount of resistance against using either of those with some people. So, not much of a problem and it's been kind of solved anyway.

nubinetwork 3y ago

Sounds like OP wants to run qubes. How cute. I wish them luck, because it also has "escape" vulnerabilities.

weare138 3y ago

As a long time Linux enthusiast and engineer this needs to be said and it's been overlooked for way too long. We need to figure out how to move past some of the traditional UNIX ways of doing things like apps keeping plaintext passwords in 'hidden' dotfiles. Even simple things would go a long way like making it straight forward to install packages from distro repositories in userspace. Every time you install a desktop app via the package system you're rolling the dice by giving the package root access. In fact that should be the default behavior for installing the vast majority of Linux apps. If an app doesn't legitimately need root access for anything we shouldn't grant it to begin with. Don't get me wrong Linux distros do a great job at maintaining security overall but these projects are massive now and in the age of supply chain attacks and hostile nation-state actors all it will take is one package to slip through to cause a major security incident. The Solarwinds hack was the proverbial canary in the coalmine. If it can happen to them it can happen to anyone. It's not a matter of if now but when.

nathants 3y ago

little snitch seems to be the correct approach. almost every compromise that isn’t target will attempt odd looking network connections. we need more little snitch like things, including for filesystem access. we also need the ability to run little snitch in paranoid mode, where the approvals happen on a separate device, sign each message with a key not on the primary device, and the validation is baked deeply and irrevocably into the kernel. smartphone face up on desk left of keyboard would work well for a second device. linux lsm seems to work[1], and building the kernel is easy locally[2] or on cloud[3]. hopefully we see more and better use of lsm and custom kernels. we all should want our most trusted public key baked irrevocably into the kernel. personalized linux is the next frontier! 1. https://github.com/nathants/mighty-snitch https://github.com/nathants/mighty-snitch 2. https://github.com/nathants/mighty-snitch/blob/master/kernel/arch/PKGBUILD https://github.com/nathants/mighty-snitch/blob/master/kernel... 3. https://github.com/nathants/mighty-snitch/blob/master/kernel/alpine/build.sh https://github.com/nathants/mighty-snitch/blob/master/kernel...