oss-sec mailing list archives
Re: sandboxing,of upstream programs by distros
From: Demi Marie Obenour <demi () invisiblethingslab com>
Date: Sat, 14 Oct 2023 13:07:30 -0400
On Sat, Oct 14, 2023 at 06:39:49PM +1100, Matthew Fernandez wrote:
Hi all, I asked Alexander about this off-list in relation to his thread “linux-distros list membership application - CIQ Rocky Linux Security Team” but he suggested I bring it on-list instead. Is there interest/solutions within the Rock Security SIG or other distro’s security teams for sandboxing that package upstreams can opt into? To step this out a bit… we have a large, old code base that was written decades prior to current best practices. It has numerous known memory safety issues and ever-dwindling maintainer capacity. It is also a dependency, either directly or indirectly, of a significant fraction of the world’s software. I am guessing this scenario sounds uncomfortably familiar/common to many on this list.
Which software is this? Are there plans to at least fix the known memory safety problems? If not, I think it would be best to disable the known-vulnerable features by default. If the entire software package is vulnerable, I recommend deprecating it and recommending that downstream users migrate to a more secure alternative.
We (the maintainers) have discussed sandboxing as a way of mitigating the risk of known bugs. However, one of the problems is that we don’t know the complete set of required privileges of our dependencies. The software can be configured with or without various libraries and also has a plugin mechanism for dynamic code loading. Basically if a sandboxing solution like seccomp wants to know our full set of system calls, we ourselves don’t know it.
You have to be willing to break compatibility to at least some degree. If you try to support everything, you wind up with something like Qubes OS’s “convert to trusted image”, which creates and destroys an entire virtual machine for every operation. Even then, you will still break a (hypothetical) plugin that accesses the Internet, because that VM should not have network access. What I would do is compile a list of system calls that are reasonable to make after startup. Once all plugins have been loaded and all configuration files have been read, no plugin should be opening files or making network connections. If it does, that plugin is broken and needs to be fixed. You can have these system calls fail rather than killing the entire process, but you cannot try to support arbitrary plugins. That said, I expect most existing plugins will work fine with sandboxing.
The downstream maintainer packaging the software for, e.g. Rocky, does though. They have a complete picture of which libraries/features are enabled and how locked down the plugin stuff is. So, where I’m going with this, is that if the various packaging ecosystems could (or do) offer sandboxing to upstream, people like us would gladly opt in to it. Of course, these downstream maintainers can already seccomp our software today. But expecting them to reverse engineer our exact needs seems a bit much. I’d be interested to hear any thoughts on this.
-- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description:
Current thread:
- sandboxing,of upstream programs by distros Matthew Fernandez (Oct 14)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 14)
- Re: sandboxing,of upstream programs by distros Matthew Fernandez (Oct 14)
- Re: sandboxing,of upstream programs by distros Solar Designer (Oct 21)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Bob Friesenhahn (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Bob Friesenhahn (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 14)
- Re: sandboxing,of upstream programs by distros Mickaël Salaün (Oct 22)
- Re: sandboxing,of upstream programs by distros Matthew Fernandez (Oct 22)