Your workstation will never be secure. Ever. It's not possible. Give up and work to implement zero trust. Ephemeral environments like CI/CD are not inherently secure because they're ephemeral either.
Toolship: A more secure workstation
21–30 of 59 posts
Re: Toolship: A more secure workstation
#22Interesting approach to maintaining a clean dev environment using containers. This approach reminds me of Fedora Silverblue[1] that I’ve been wanting to try. It leverages OSTree for atomic upgrades and rollbacks. Users can run containers for CLI utils using toolbox[2]. This way, the base OS remains pristine, and there's less risk of "dependency hell" or inadvertent “package upgrades gone wrong”. [1]: https://fedorapr…
I have silverblue on a laptop, but hadn't poked about sufficiently yet. Toolbox looks great. Thanks for pointing it out.
Re: Toolship: A more secure workstation
#23I was nodding along until it became clear the Docker containers were being run as root...
Since the author of this post is making efforts to bind mount specific directories, is that still a legit risk? root inside the container isn’t essentially the same root on host. But yes, UID and GID mappings along with user namespacing will be better.
But you have to be root outside of the container to run Docker. Which means the author has to run every single little command as root. That violates the principle of least privilege, increases the potential damage caused by bugs or mistakes, and therefore is a very legit risk.
Also notice how the shell snippets in the article doesn't use sudo to run docker. That indicates that the author probably added their user to the docker group, which is equivalent to always logging in as root. That's terrible, terrible security practice.
I can't agree that root inside the container is different from root on the host, either. The kernel makes no such distinction unless user namespacing is enabled. When containerized processes gain access to host resources, whether intentional or not, they'll have the same level of access as root on the host.
Re: Toolship: A more secure workstation
#24Docker seems a bit unwieldy for this use case. Given it runs in a Linux VM on macOS, wouldn't all these commands have considerable overhead? On Linux, the pledge utility[1] seems like a better fit for this. I'm not aware of what the macOS alternative would be, but considering this functionality stems from OpenBSD, maybe it can be ported to Darwin? [1]: https://justine.lol/pledge/
Mac doesn't have seccomp so no. The functionality could be implemented but it would have to use a completely different mechanism.
Re: Toolship: A more secure workstation
#25A more extreme version of this would be to install something like Prox-mox on a machine (doesn't have to be the actual machine you're using, but probably could be) instead of the standard OS, and then create virtualized containers for each "use case" (and then use good security practices on each containerized OS as well of course).
Setup correctly, if any one container was to get compromised, it shouldn't leak out to anywhere of the other ones. Would be super inconvenient, I'm guessing to actually have a semblance of efficiency there would still likely be a "main" container and you'd SSH into others in order to do tasks associated with that container. Not too much different than the "clean OS" described here, probably the helper scripts could be similarly adapted to utilize the individual containers instead of docker containers.
I personally would be hard pressed to consider something like that, but seems like the logical continuation of this type of machine configuration/setup.
Re: Toolship: A more secure workstation
#26I have been thinking how to work with multiple users in a convenient way. The problem is that file permissions causes problems when you want to switch between users. I have not found a really ideal way of working using different users, but I think it needs some approach, I just haven't found it yet.
Does group membership not help?
Re: Toolship: A more secure workstation
#27A more extreme version of this would be to install something like Prox-mox on a machine (doesn't have to be the actual machine you're using, but probably could be) instead of the standard OS, and then create virtualized containers for each "use case" (and then use good security practices on each containerized OS as well of course). Setup correctly, if any one container was to get compromised, it shouldn't leak out to…
Re: Toolship: A more secure workstation
#28Your workstation will never be secure. Ever. It's not possible. Give up and work to implement zero trust. Ephemeral environments like CI/CD are not inherently secure because they're ephemeral either.
If we assume a workstation compromise, why would we trust the zero trust infrastructure that was set up with that workstation?
Re: Toolship: A more secure workstation
#29Earlier quoted context omitted.
Since the author of this post is making efforts to bind mount specific directories, is that still a legit risk? root inside the container isn’t essentially the same root on host. But yes, UID and GID mappings along with user namespacing will be better.
But you have to be root outside of the container to run Docker. Which means the author has to run every single little command as root. That violates the principle of least privilege, increases the potential damage caused by bugs or mistakes, and therefore is a very legit risk. Also notice how the shell snippets in the article doesn't use sudo to run docker. That indicates that the author probably added their user to…
Noted. Yep, valid points. Thanks for explaining!
Re: Toolship: A more secure workstation
#30Your workstation will never be secure. Ever. It's not possible. Give up and work to implement zero trust. Ephemeral environments like CI/CD are not inherently secure because they're ephemeral either.
If we assume a workstation compromise, why would we trust the zero trust infrastructure that was set up with that workstation?
You can't trust it. One of the first real lessons security work teaches you is that nothing can ever be perfectly secure, it's all about achieving a level of security that is appropriate given your threat model, and gives you enough confidence to be able to sleep at night.
There's steps you can take that involve incredibly secure procurement processes of air gapped devices, but even that will not prove absolute security.