Practical security for supply chain attacks?
I'm considering running OpenBSD on my laptop, but I'm concerned about supply chain attacks—both in transitive dependencies of packages added via pkg_add, and in dependencies of software I'm actively developing and building.
On something like Fedora, I have Flatpak + Flatseal for GUI apps like Firefox and GIMP, and I have good VM options for command-line applications and for building software.
On OpenBSD, however, all I really have are chroot, pf rules (to limit Internet access for certain users to specific servers), Xephyr, and the usual permissions model. OpenBSD's VMs are too slow, and pledge/unveil is not often applicable.
Has anyone else given this a lot of thought? Thanks in advance!
Jun 27 · 11 days ago
8 Comments ↓
🐐 drh3xx [mod] · Jun 27 at 22:52:
VM's with VMD/VMM are only single core currently (unless I've missed some news on that front). I'm pretty sure QEMU is available though, if you're happy to trust the provided pkg or port. There have also been several improvements made regards general network performance so VMs should be viable.
What kind of threats are you worried about that you aren't sure OpenBSD would protect against sufficiently? If you a can state a particular class or classes of threat then perhaps someone could point you to a feature or set of capabilities that would put your mind at ease.
🛰️ repeater [OP] · Jun 28 at 00:07:
@drh3xx: Thanks for the reply!
Yes, it seems vmm still has no SMP support for guests. QEMU is available, but performance is very poor on OpenBSD, I assume.
My main concern is malicious packages in repositories like crates.io, opam, and Hackage, as well as in dependencies of language servers and editor plugins. I am trusting thousands of people, any of whom could be malicious or have a compromised GitHub account, whenever I do software development.
I know no one will likely bother to slip in an OpenBSD kernel exploit, so I think a chroot is probably fine. It feels less secure than a VM though, and I'm not sure it's acceptably safe to run such code locally, even with basic precautions.
do you trust openbsd packages?
i don't know openbsd world well, so i don't understand if your concern about rust packages is about packages/ports/recipies in openbsd ports tree.
i guess openbsd ports tree contains packages/ports that install/build only code which was looked at by many people. no?
i guess openbsd recipies don't fetch unknown code with cargo.
🛰️ repeater [OP] · Jun 29 at 05:16:
@norayr: I trust some OpenBSD packages, especially those of well-established pieces of software with minimal dependencies and large communities, but I trust other packages less so. It's not any given port that's the issue, but rather the hundreds of transitive dependencies and thousands of developers involved in the software itself. Malicious packages have been found in crates.io, npm, PyPI, and elsewhere, and such packages can easily be dependencies of applications in OpenBSD's ports tree. These attacks are increasingly common, unfortunately.
that's what i am trying to ask. how is that possible that random code from crates.io is packaged?
ok my understanding is that operating systems: linux distributions or bsds or others, each have a policy describing how to deal with code written with go, rust, python, etc. python is old, so the practices are well established: each python library that could be installed otherwise with pip, is packaged. the package has version, the source code snapshot is copied to debian or gentoo directories, fingerprints and signatures are used.
of course i understand the problems with building rust/go/js/etc programs, when package manager brings you incomprehensibile amount of source code. i don't recommend doing that.
usually my recommendation is to only use in your code those go or rust etc dependencies, and those versions, that are available in your os package manager.
and when debian makes packages of go programs, they package each dependency separately.
while that does not exclude probabillity of malicious code, it decreases that probability significantly because the process of packaging involves many steps and many people, and code passes through some institutionalized pipelines.
debian package of go program is not being built by simply downloading all dependenies as is at some point in time and building a package from all of them.
i have some experience with freebsd packaging, and it is the same: package builder will not
will not download files during the build.
so i assumed using packages is safe enough.
is what i described the case with openbsd packaging too? do they build a package for a go program by downloading lots of random deps or do they package each dep separately?
what improvement is flatpak bringing? i don't know well how it works.
it can work without root privileges, right? it brings you some sets of precompiled binaries, and it is not clear what those sets contain, those are sets of software that is not packaged, it just comes as one layer and has lots of stuff and repeats what your os already has.
i find it unnecessary complicated and disk space hungry abstraction.
🛰️ repeater [OP] · Jun 30 at 07:16:
If there is a package P for some Rust application A, and that application has some dependency X, which itself has some dependency Y, and the author of Y's GitHub account is compromised and Y has malicious code added in a new version, all that has to happen are some dependency bumps for P to be compromised too. The author of X is likely not studying the changes in Y, and the authors of P and A are almost certainly not either. The same problems are there when building software and pulling down dependencies to an even greater degree—which, as a software engineer, I cannot avoid doing.
While a VM is more secure than chroot + pf rules, I do think the latter is probably fine. A lack of setuid/setgid binaries leaves few avenues for privilege escalation, and a reverse shell is not possible given the firewall. Also, the chance that any given bit of malware contains an OpenBSD-specific exploit is far below 1%.
All that said, I still wish vmm had SMP support for guests. I'm not offering to write it, so I can't complain, of course. Hopefully, they'll get there in the coming years. In the meantime, perhaps I'm better off running Linux for the sake of hosting VMs if I want the added security, any of which can be running OpenBSD.
🐐 drh3xx [mod] · Jun 30 at 11:31:
I think you should be OK with OpenBSD using chroot and pfrules. Could you isolate further using per app routing domains? I'm also hoping VM client SMP will materialise.
OpenBSD has a lot of memory based protections too such as W^X, guard pages and use of ASLR.
Other than that I can only make the painful recommendation not to trust crates.io, npm etc... pick particular versions or git commits and audit all the code. Then if you have to upgrade a dependency for a project audit the diff's since (thankfully should be much quicker) and choose more established dependencies in general as they should be more stable code bases between major releases. I wouldn't recommended using any unaudited code in general.
🛰️ repeater [OP] · Jul 01 at 05:44:
@drh3xx: Yes, upon further reflection, I feel safe enough forging ahead with OpenBSD. I'll give it a try! Thanks for your comments.
As for crates.io and the like, I definitely do not pull in unaudited dependencies for my own projects. I do, however, sometimes want to contribute to an open-source project that is not my own, and it's not realistic for me to audit everything before I check out the project and build it (and its myriad of dependencies). Depending on the scale of the project and the language(s) involved, I may be able to get away with vmm in such cases.
Source