Hacker News Reader

Comment by emerongi | Hacker News Reader

My main OS is Fedora Silverblue, which is "an immutable desktop operating system". I install GUI software through Flatpak. For development, I run a VM (Fedora Server) and connect to it through SSH (VSCode works really nicely here). I have different VMs for different use-cases, but mostly I work in just two "fat" VMs. I try to be diligent in what I install and use in the main OS as well as in the VMs.

It's not entirely safe, but I think gets me 90% of the way to a reasonably safe workspace. If there is malware in a VM, I can nuke it and reset affected credentials in my main OS (which is not infected). It's not too much extra overhead, I just SSH into the VM and work as usual. I've used Qubes before and have also tried a fully Docker-based workflow (developing exclusively in containers), but there can be too many headaches with either.

View on HN

I like your setup. It's important to point out to users that there is no such thing as "safe" in the absolute sense, only degrees of safety.

I think that a combination of what you're already doing and living a few releases behind the latest is about as safe as we should hope for on our personal machines.

GUIX and NixOS can similarly create an immutable root system + packages. System and app state is still stored in /var and /home/me, but the system and installed packages are unalterable.

There was a good blog post a few months ago on further hardening NixOS: https://christine.website/blog/paranoid-nixos-2021-07-18

I always get the impression an immutable OS is solving the wrong problem. It protects the OS - all the data I don't care about - but does nothing to protect /home/me, which is everything I do care about.

How is this solved?

Agreed entirely. It wouldn't even solve the attack described in the post; a malicious VSCode plugin (as that would be ran from your /home folder somewhere.

It feels so many security ideas fail to protect the /home dir which contains 99% of important data that needs secured, and instead focus on the OS. I understand that for servers and hypervisors, but it feels like so little effort goes into desktop OS on this.

Basically, desktop OSes need to become more like iOS and Android in how they ask for permissions and segregate apps from each other.

macOS does _a little_ of that, although limited to certain "special" folders (Documents, Desktop, Downloads, ...) and people call it macOS Vista for it.

Note: I like that it does that and would like this capability to be expanded and refined.

It's a start for sure but there is so much low hanging fruit here.

Eg a warning/prompt if a program tries to read/modify/delete more than x files in your home directory (not including its own config files). This would stop an entire class of malware scanning for passwords or secrets in your home folder. It could even if implemented right stop some of the ransomware attacks after a few files.

It seems crazy that so little effort is put into this kind of thing vs the crazy level of effort that goes into hardening the OS.

Prevention and detection of tampered files in /home/* is definitely a major aspect of 'Securing the workstation'; As attacks are not just for exfiltration of data and could very well be to place .murder_VIP.doc; There seems to be a need-gap[1] for solutions in this space.

But considering immutable OS increases overall security of the system and that the system/software likely has to be compramised first to tamper /home/* I think they're useful to prevent this attack as well.

[1] https://needgap.com/problems/188-proving-computer-hack-proof... (Disclosure: I run this problem validation forum).

Correct. Immutability does very little for security: attackers are interested in reading your files, extracting your authentication data e.g. session cookies and little else.

What really helps is application sandboxing, e.g. with firejail.

Silverblue sounds promising. "Entirely safe" is just shy of impossible, but I feel like a reasonable and responsible degree of security should be possible without too many sacrifices.

Silverblue has its own restrictions and might not be ideal for your specific workflow, but it works for me as a sort of base OS.

There's a lot more that could be done to advance the security aspect of Linux. Flatpak is an improvement as it requires applications to declare the permissions they need, however it still has a ways to go. I wish there was a tool to monitor if some random process is accessing folder X or has high network usage, a'la Little Snitch on Mac. Linux desktop doesn't have a ton of manpower behind it though, so it all takes time.

Fantastic workflow!

Is there anything immutable like that on the Debian side?

Half a year ago it looks like there wasn't anythinghttps://www.reddit.com/r/Ubuntu/comments/lbyo9o/is_there_any...

No, as far as I know. I haven't used Debian-based distros in years, so I'm unsure of the situation there, to be fair.

There are other approaches, e.g. Guix and NixOS as mentioned by others, but you also can get most of Silverblue's benefits from BTRFS/ZFS and a package manager that can create snapshots. Not sure if apt integrates like that.

For me, Silverblue just enforces good defaults: the base OS is as simple as needed and I only install necessary applications through Flatpak, which has some security benefits over direct package installations. VMs are for more involved work with potentially risky software (i.e. development environments with random NPM dependencies).

Silverblue is the most promising development in the Linux space. I used it for years before switching to a MacBook. Sadly too many Linux users are stuck in the mindset that you should audit the code of every app you run and that the user/root split is all that is needed for security.

Are you running Silverblue on Mac?

I have a Thinkpad.

Let’s hope the vulnerability isn’t injected into all the deps your OS pulls down to run the VM

Physics informs us a perfectly secure system is impossible.

We need to socially accept it rather than make ourselves paranoid.

You can never have a totally trustless system, but I think we could trust our applications a lot less than we trust them now.

It's not all or nothing. We don't need to give up because some aspects of a system are insecure. There are different threats and different answers.

Qubes got it right in its philosophy. We either get system secured by correctness or by isolation. The former is not possible on a Linux developer machine.

There's a middle ground between accepting and paranoia: secure to best effort.

Reply on news.ycombinator.com