[HN Gopher] Ask HN: What's the best way to secure your workstation?
___________________________________________________________________
Ask HN: What's the best way to secure your workstation?
Here's a very plausible threat: Some developer with a left-pad
package, some dependency-of-a-dependency, injects malware into
their library. A developer (who is broadly trustworthy) updates
their package's dependencies without auditing them properly, and
the malware ends up in a VSCode plugin that you use. You open
VSCode, your system is infected. 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?
Author : bccdee
Score : 71 points
Date : 2021-11-28 17:55 UTC (5 hours ago)
| tonymet wrote:
| develop in a VM.
| ptx wrote:
| Is there a good solution for getting good graphics performance
| with VMs, aside from using QubesOS and its special shared-
| memory thing[1]?
|
| 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/
| bosse wrote:
| I'm currently looking into NICE DCV[1] from AWS after
| learning about it in a podcast with Michelle Brenner from
| Netflix.[2]
|
| 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/
| guilhas wrote:
| x2go is fast, not sure how secure
| OJFord wrote:
| Unless you use a different VM for everything, you've just moved
| the problem from 'secure your workstation' to 'secure your VM'.
| jrexilius wrote:
| As long as the container isn't leaky, the benefit there is
| that it makes recovery, back-ups, and isolation easier. For
| example, dev VM isn't where you would have your creds for
| bank, SSH keys, etc. So isolation of (more) sensitive, daily-
| use data is easier. Snapshots of VM are cleaner and fast to
| rollback, etc. The OP was looking for reasonable mitigations
| that don't make daily usage a complete drag. I think VMs or
| other containers fit some of that bill.
| formerly_proven wrote:
| > Unless you use a different VM for everything
|
| Why yes, that's exactly the idea.
| p2p_astroturf wrote:
| There's nothing you can do. All language library distribution
| systems ever made are insecure, and backed by willful ignorance.
| closeparen wrote:
| Some things you can do to mitigate the impact of a developer
| machine compromise:
|
| 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.
| OJFord wrote:
| At first I was going to say (a) only works if everyone does
| that, or you refuse to use anything that doesn't (which I
| suppose is slightly easier than auditing everything you use...)
|
| 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?
| bccdee wrote:
| Yeah I was more worried about an attacker getting my bank
| account details than an attacker compromising a codebase I
| work on.
| PeterisP wrote:
| IMHO the same reasoning applies for the personal machine -
| you can _reduce_ the risks quite significantly, but you
| should expect that you won 't be able to fully secure it and
| after the basics (like keeping up to date with patches and
| not running unusually untrustworthy software) are done, the
| next most effective steps would be more about mitigating the
| consequences in the case the machine is compromised, not
| expecting to be able to prevent it from being compromised.
| It's not a _common_ occurrence to get your machine owned, but
| it 's also not entirely preventable, some risk is always
| there.
|
| 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.
| emerongi wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| 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.
| [deleted]
| butMyside wrote:
| 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.
| bccdee wrote:
| 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.
| emerongi wrote:
| 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.
| atVelocet wrote:
| Use Windows Sandboxing which is builtin or have the dev run a VM
| which only exposes needed ports. Dont make things to
| complivated...
| GhettoComputers wrote:
| It's easy, set up a good firewall on your router, disable
| constant internet access on a computer with an airgap, don't
| update for the sake of updating, remove the LAN cable/WiFi card
| if you're really worried.
| mmaunder wrote:
| I don't think this is the right question. How do we secure our
| code, our data, and our supply chain is the right question. Most
| of our work environments span multiple endpoint hardwares and
| virtual instances and our data is spread across these devices and
| cloud services. It's a harder problem but let's start by defining
| what we're protecting and then work it.
|
| 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.
| perlgeek wrote:
| Some scattered thoughts on this:
|
| * 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".
| rtkwe wrote:
| > * 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.
|
| It always feels like advise that relies on not everyone
| following it is cheating just a bit.
| cogburnd02 wrote:
| Have an air gap between development machines and anything
| attached to the internet.
|
| Or just put your machine in a bank vault.
| can16358p wrote:
| And what if you are developing something that interacts with
| the Internet?
| progval wrote:
| > 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. [...]
|
| > 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.
| vesche wrote:
| One option would be to not run vscode locally:
| https://github.com/features/codespaces
| AreYouSirius wrote:
| it is trivially easy
|
| https://edition.cnn.com/2013/01/17/business/us-outsource-job...
| hvgk wrote:
| With modern software distribution infrastructure you are entirely
| fucked at this point. It's number one business critical risk from
| our analysis. And it's not just from developer workstations but
| from stuff sneaking into production during a build cycle as well
| which is flagged through or missed by any of the participating
| tools which are supposed to stop stuff going through. The
| developer workstations aren't even a worthy target.
|
| 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.
| Kranar wrote:
| >Imagine if someone managed to inject malware into a core
| kubernetes component which gets pulled from docker hub or
| something.
|
| Digital signatures are a typical way to protect against this.
| Pretty robust as far as I know.
| [deleted]
| hvgk wrote:
| Digital signature tells you that the owner of the key signed
| it. Not who currently owns the key.
| freedomben wrote:
| Some of the easiest things you can do regardless of OS are to use
| containers when developing (so you aren't installing npm packages
| on your host/main system), and don't store sensitive credentials
| on your disk in plain text (like in `~/.aws/credentials`). Use
| env vars and only export them when needed.
| yjftsjthsd-h wrote:
| Yeah, I started to worried about this but then realized that
| virtually all of my development work happens in containers
| anyways for purely practical reasons, and it's not like I'm
| mapping my real home directory in or anything, so if I had a
| compromised module or something it would affect that project
| but nothing else - all without me having to take any special
| security measures.
| rfoo wrote:
| Unpopular opinion: I disable auto-update and for every piece of
| software I use, I go over it at least casually, or wait some days
| depending on how popular it is and the "trust level" in my mind,
| before first load and before update.
| lupinglade wrote:
| Seems like a problem with VSCode.
|
| 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.
| m4x wrote:
| VS Code plugins extend the functionality of VS Code, not the
| apps you write with it.
|
| 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.
| formerly_proven wrote:
| > If your app is made up of more packages and dependencies than
| you can audit then you're doing it wrong.
|
| 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.
| bsenftner wrote:
| I totally agree. I am bewildered by the large number of
| developers working in such blind, insecure environments.
| Entire tech sectors that grind to a halt when github does
| down. It is insanity.
| fsflover wrote:
| > How do you secure your workstation without living like a monk?
|
| Using Qubes OS. It's really easier than you might think. The UX
| is amazing. Can't recommend it enough.
| mushufasa wrote:
| When I've been on video calls with people using Qubes
| (admittedly rare, since few users), they inevitably can't get
| video or sound working or have to wait 5-10 minutes into the
| call for them to re-enable some system access to drivers for
| the window for the video call.
|
| 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.
| fsflover wrote:
| Video calls work fine for me. It's all about the Linux-
| compatible hardware. Here is a good list:
| https://forum.qubes-os.org/t/community-recommended-
| computers....
|
| 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.
| PeterisP wrote:
| There's no reason why everything should happen on the same
| machine, hardware is relatively cheap. Don't shit where you
| eat; don't do your web browsing / videoconferencing /
| exploration of interesting new tools on the same machine from
| which you have privileged access to sensitive things.
| Virtualization is an option, but just buying an extra laptop
| might be more straightforward.
| panarky wrote:
| _> Don 't shit where you eat_
|
| 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.
| _alex_ wrote:
| I've been thinking about something similar. I have an old
| laptop that I've been thinking of throwing proxmox or
| something similar on and just hosting VMs for my "daily
| driver" laptop to connect to
| sokoloff wrote:
| I find myself frequently wanting to screen share the things
| that I'm actively working on. I suppose I could use HDMI
| capture and confine myself to sharing only full screens
| (which might suck for viewers at 4K res or require me to
| switch to 1080p on that screen), but for a lot of people
| there is perhaps more overlap between video conferencing
| and work than full segregation would support.
| craftinator wrote:
| If you're on Linux, xpra might be an option here. Just
| stream the rendered window from your sensitive access
| computer to wherever you need to show it.
| bccdee wrote:
| Yeah, the more I think about it, the more it seems like this
| might be the way to go. What are the drawbacks? I know GPUs are
| hamstrung, so gaming isn't viable. But I can use another
| machine for that. What else?
| fsflover wrote:
| The main challenge is that you need to adjust your workflows,
| making them separate for separate security domains. For
| example, never run untrusted application in a trusted banking
| VM etc. Otherwise there is this: https://forum.qubes-
| os.org/t/major-ux-pain-points. Many of those pain points are
| solved by Qubes 4.1, which is not released yet, but there is
| a release candidate: https://www.qubes-
| os.org/news/2021/11/17/qubes-4-1-rc2/.
|
| > I know GPUs are hamstrung, so gaming isn't viable.
|
| Technially, you can also make a GPU passthrough.
| digitallyfree wrote:
| Not too familar with Qubes, but it looks like it offers
| security by using virtualized domains (e.g. one for your dev
| environment, another for personal browsing, etc.) and the
| interactions between the domains are controlled. However, in
| the OP's case of a VSCode plugin containing malware, his entire
| dev domain will as a result be compromised as a result of this
| plugin. If he uses the same VSCode plugin in his personal
| domain as well, that will also get compromised.
|
| 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.).
| fsflover wrote:
| Yes, Qubes provides security with virtual machines. You can
| compartmentalize you dev environment further: develop
| different things separately and use disposable virtual
| machines for most untrusted stuff. Also, you can
| simultaneously harden your development VMs.
___________________________________________________________________
(page generated 2021-11-28 23:01 UTC)