sandboxing,of upstream programs by distros

[Matthew Fernandez <matthew.fernandez () gmail com>]

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.

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.

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.

Thanks,
Matt