[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Oct 2023 13:07:30 -0400
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Subject: Re: sandboxing,of upstream programs by distros
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
