Ask HN: What's the best way to secure your workstation?
We know this sort of malware is making its way onto package repositories [1]. We know people are falling for these attacks. How do we protect ourselves against this family of threats?
[1]: https://www.theregister.com/2021/07/21/npm_malware_password/
We could trust nothing beyond our base system and our browser, and refuse to use any code we don't fully audit, but this would be an impossibly austere way to live. I expect most of us, when pressed, would admit that we're trusting much more code than we would like to.
The alternative is sandboxing, using a lightweight option like firejail (which I use) or a totalizing system like QubesOS. But these systems are awkward to use, and have their own drawbacks.
What's the bar for reasonable security, in your opinion? How do you secure your workstation without living like a monk?
93 comments
[ 7.6 ms ] story [ 123 ms ] threadUsing Qubes OS. It's really easier than you might think. The UX is amazing. Can't recommend it enough.
> I know GPUs are hamstrung, so gaming isn't viable.
Technially, you can also make a GPU passthrough.
Not a problem for a developer who mostly communicates internally with a singular video call setup that you can optimize. But impossible for a founder, executive or salesperson that constantly has to be interacting with every video/call system in existence and doing screenshares and everything.
Apart from that, on Qubes you need to manually choose which VM will have access to a microphone and camera, so it may take an additional minute (but not ten minutes!). Persistent connection to a chosen VM should also be possible.
1) Chromebook for web, social media. Separate profiles for personal trusted (banking), personal untrusted (browsing and social media), office/client work.
2) Separate laptop as VM host for development. Never pollute the host with third-party libraries or anything downloaded from the web, all that happens in disposable guests.
3) ssh and sftp from Chromebook to VMs as needed.
I wonder if an approach similar to Firejail would work better, by say severely restricting what VSCode can do (e.g. what directories it can access, controlled network access, etc.).
Or just put your machine in a bank vault.
If you use both host & VM I think my point stands, the host may as well be another VM (or the VM another physical machine) it's not that it's virtual that's adding anything, it's the separation, which was my point.
Why yes, that's exactly the idea.
It still goes a long way to reduce fallout with minimal effort & discipline.
You’re right it’s not perfect security, VM still needs securing – but it’s a good ROI
Plain X11 is obviously out of the running, as that gives clients far too much access. Apparently[2] Xpra or xephyr can help here, but to what extent and how does it affect performance?
Wayland seems to use both sockets and shared memory somehow. Can that work with a VM or container? How? Is there another solution? (Pipewire?)
VNC works but doesn't perform well. SPICE might be slightly better?
[1] https://www.qubes-os.org/faq/#whats-so-special-about-qubes-g...
[2] https://firejail.wordpress.com/documentation-2/x11-guide/
My use case is on-prem, but it seems like this solution can run cloud agnostic.
[1] https://www.nice-dcv.com/
[2] https://www.infoq.com/podcasts/netflix-builds-workstations/
If you're serious, then you want to search for GPU passthrough. This allows a VM to take control of an entire GPU. But you'll need a 2nd GPU for your main, bare metal OS.
a) Don’t let anyone push to master. Everyone goes through code review.
b) Limit access to production. If you’re a shop with a separate ops function, none at all. If developers do their own basic ops, then limited and structured control surfaces for them. Choose from among the code reviewed builds to deploy, that sort of thing.
c) Where relatively high privilege in production is required, provide dedicated workstations just for that. These don’t need arbitrary local software or even internet access generally, just the production VPN.
But after reading (b) & (c) I think you're answering from a business perspective about this risk on employee machines? I read OP's question to be more about employee's own risk, or if the answer's 'work machine is for work only' then what about the personal machine?
Like, for personal use - have offline backups that protect you if your machine gets ransomwared; don't keep the keys to your cryptoinvestments on the same machine as the VSCode plugins OP mentioned; etc.
As a starting point I think crowd wisdom is called for given the size of the challenge this would be for an individual. If you see something, immediately say something. Responsible full disclosure on tight timelines. Ways to rapidly get the message in front of those impacted where action by them is needed. Build systems to avoid requiring action from those affected without compromising freedoms.
https://edition.cnn.com/2013/01/17/business/us-outsource-job...
Write more of your own code. If your app is made up of more packages and dependencies than you can audit then you're doing it wrong.
Consider OpenBSD.
Many of them are excellent, and it doesn't make sense to eschew their use just because you can't realistically audit their code.
And I guarantee you're also using a huge amount of code you don't and can't audit.
My current employer has a policy where every dependency needs to be part of the software BOM (except it's FAR more comprehensive than what passes as an SBOM in the industry, it's an excel sheet that goes into the double-letter columns, including, among many other things, a rationale for why you're using $thing) and signed off by legal (a process taking some time). It's kinda irritating to do, but it also opened my eyes how completely unauditable e.g. npm-based projects are. Not that I had a high opinion of npm before. The other day we had a thread here with a similar topic and someone said "No one knows how to do builds without the internet", someone else chimed in saying that Flutter (or some other framework) actually can't do offline builds; pip is actually somewhat similar, as PEP517 causes it to try and run for PyPI even when installing packages purely from a local source; this can be easily disabled though.
Those things are utter insanity to me. You have no control. You have no idea what code you're running now, let alone tomorrow. Your builds will never reproduce, and your CI is going to fail whenever some random cloud webshit goes down.
Same for VSCode btw. ... it's not even shared source.
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.
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.
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.
Physics informs us a perfectly secure system is impossible.
We need to socially accept it rather than make ourselves paranoid.
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 was a good blog post a few months ago on further hardening NixOS: https://christine.website/blog/paranoid-nixos-2021-07-18
How is this solved?
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.
Note: I like that it does that and would like this capability to be expanded and refined.
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.
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).
What really helps is application sandboxing, e.g. with firejail.
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...
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).
> The alternative is sandboxing, using a lightweight option like firejail (which I use) or a totalizing system like QubesOS.. But these systems are awkward to use, and have their own drawbacks.
I am somewhere between these two options, to be reasonably secure without experiencing too many drawbacks: All my software is installed either from Debian repositories, or compiled myself and ran as a application-specific unprivileged user, with no access to X/Wayland when possible. (You could allow yourself to download binaries, but source makes me feel somewhat safer.)
I also run Firefox and VLC in Firejail because they are complex pieces of software that deal with lots of untrusted input, and need access to X/Wayland.
* Don't always immediately updated to the newest version. If it's compromised, give the other users and the vendor time to find the vulnerability.
* Try to rely on software packaged by somebody you trust.
* Reduce potential impact of compromise by using 2FA with something off your dev machine (like authenticator app on your phone).
> What's the bar for reasonable security, in your opinion?
That really depends on your situation.
Do you think somebody might target you, specifically? Has your machine been compromised before? Do you do anything with potentially high leverage for an attacker?
If the answer is "no" to all these, I'd say don't sweat it too much beyond standard "best practices".
It always feels like advise that relies on not everyone following it is cheating just a bit.
I wait a few months. Someone else only waits a week.
Imagine if someone managed to inject malware into a core kubernetes component which gets pulled from docker hub or something.
The only reasonable way to prevent this is do development work in a fully constrained environment both from a hardware and software perspective and that means taking on a hell of a lot of compromises which will cripple your productivity entirely.
My efforts to investigate this pretty much lead to the conclusion that you need to have two computers available attached to different physical networks. The first computer has internet access and allows things like email, www access but has no administrative capabilities and no development tools installed and no way of installing tools as an unprivileged user. The second computer is the only one you are allowed to do development work on and has no internet connection.
Obviously when proposing this, it was laughed out of the room. This is exactly what I intended to prove: you can’t fix this reasonably at this point so don’t bother doing it.
At least not unless you have an airgapped machine and solely write in something standardised, with no external dependencies or libraries and no possibility of pulling something from outside your trust boundary.
I hope you sleep better than I do knowing this as well.
Edit: I was actually most happy writing C in an airgapped network about 25 years ago on a Sun machine with some manuals and some Oreilly books on my desk. The very thought of downloading something there was laughed out of the room. I wonder what they do now.
Digital signatures are a typical way to protect against this. Pretty robust as far as I know.
https://kubernetes.io/docs/concepts/overview/components/
All resulting research data was on the airgaped network where each terminal was heavily restricted in what it was allowed to do and by whom.
We the software devs were on the open network, with less restrictions. Due to the concern of a supply chain attack there was a heavy feel of not invented here.
Over its ~25 years of operation the lab has created immense amounts of internal software from scratch.
It was an interesting look into a small dev team that had mostly never worked anywhere else (yes, the code was often very messy), and had a xenophobic view of off-the-shelve software and solutions.
Of course, young and inexperienced, I did not see the potential preferring mild alcoholism and socialising. Doh!
As you move through from code to production we have multiple stage gates and steps.
- From a code perspective, we use dependency and code scanning (yarn audit, sonarcloud, sonarcube etc). Sonarcloud has nice IDE integrations.
- Code is pushed and is picked up by a pipeline, further scans are done looking for vulnerabilities/CVEs etc. If any significant ones are found, the pipeline fails (yarn audit, sonarcloud, sonarcube, Palo Alto container scanner, docker bench etc)
- The pipeline deploys to test and does automated checking
- Prior to a production deployment, the pipeline must be manually approved.
- Once in production, we use further scanning and monitoring (Security Hub/Centre, Tenable, SIEM)
Our developers have no direct ability to change the production systems in any way. But, they can write code and commit to our Git repository as much as they want. Everything from that point is automated (except for manual approvals).
> Unified Write Filter (UWF) is an optional Windows 10 feature that helps to protect your drives by intercepting and redirecting any writes to the drive (app installations, settings changes, saved data) to a virtual overlay. The virtual overlay is a temporary location that is usually cleared during a reboot or when a guest user logs off.
When I first got my laptop, I installed a fresh clean copy of Windows 10, installed all my commonly used applications, configured all my settings, and then enabled UWF. On every reboot, it goes back to this clean snapshot, no matter what I do - And reboots are quick too (~10 seconds).
I like this setup because I'm never worried about making changes to my computer to try them out (installing a new program, configuring obscure settings, etc). If I don't like it, I can get back to my fresh state with a simple reboot. I also like that the feature is built into the OS - there are similar third-party solutions such as "Reboot Restore RX" [2], but I don't trust these as much, and they're not as clean as UWF.
The only downside is when you _do_ want to persist changes to update you have to disable UWF, reboot, make your changes (such as Windows Update), enable UWF again, and reboot. But I seldom have to do this. I treat the OS as pretty stateless and keep all my personal files in a separate bitlocker-enabled partition that isn't subject to UWF.
[1] https://docs.microsoft.com/en-us/windows-hardware/customize/... [2] https://horizondatasys.com/reboot-restore-rx-freeware/
Albeit in this scenario, UWF is now disabled, so future writes go directly to the disk until UWF is enabled again.
And here we are in 2021 and your dev tools are doing the same thing. Good luck with that.
At the router level you can block Tor, block VPS IP ranges etc. You can also block the entire internet and only allow ips from your browser history
Besides sandboxing you can run a firewall, I tested with some reverse shells and it does stop them. Of course a red team can do more bad stuff
It is also flashed with HEADs and I have a secret on a smartcard (usb stick) that I can use to sign my boot partition.
On the boot partition there will be a minimal system that lets me decrypt my hard drive and boot into my desired guix system generation. The boot partition is signed so it should never change (especially not every time you update your system configuration).
Guix allows you to bootstrap from a minimal seed so once I finish making the software I need for the bootstep I will set this up on that laptop by bootstrapping guix.
For me it's all about trying to go closer to the foundation a la precursor; rather than a theatre like qubes where the complexity is just too much.
In the not-as-distant-as-it-may-seem future I will probably try genode on a pinephone or a laptop and maybe it will be useable and robust..
(edit: changed link formatting)