Re: sandboxing,of upstream programs by distros

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

> On 10/22/23 11:06, Solar Designer wrote:
> > For Rocky Linux Security SIG, the only relevant thing mentioned so far
> > was possibly offering an OpenBSD pledge()-alike that other packages
> > could use.

Thanks for bringing up pledge(). That was partly what spurred this line 
of thinking – pledge() is our probable solution on OpenBSD, and it 
wasn’t clear what the equivalent approach on Linux would be.

> > Initially, we are going to only create "override' packages
> > for core or very commonly used/exposed components, and to do so only for
> > specific good reasons.  So stuff like e.g. ImageMagick/GraphicsMagick
> > coming from EPEL and with most of its dependency libraries coming from
> > AppStream repos, or e.g. GraphViz coming from AppStream, is unlikely to
> > make the cut, at least not initially.

I see. Thanks for letting me know.

> > I find the above two paragraphs somewhat contradictory…

Yes, I see what you’re saying, and I take your point. Perhaps this was a 
bit “have my cake and eat it too” on my side.

> On 10/22/23 11:45, Demi Marie Obenour wrote:
> > That said, has wasm2c been considered?  The
> > best fix would be something that can make C code memory-safe, even if it
> > comes at a performance hit

Funny you should mention this, it’s what we presently suggest to 
security-concerned users. There’s a kind downstream contributor who has 
done the necessary gymnastics to produce a WASM-ised version of our 
program. I have not looked into how they achieve this, but I would not 
be surprised if it involves something like this.

> On 10/23/23 01:19, Bob Friesenhahn wrote:
> > On Sat, 21 Oct 2023, Demi Marie Obenour wrote:
> > > If neither of these are options, I think the entire library will need to
> > > be deprecated for eventual removal.  The command-line tools can remain,
> > > but they can be much more strongly sandboxed than a library can, because
> > > they have the entire process to themselves.
> >
> > Any deprecations or sandboxing approaches which fail to understand and 
> > address the needs of the "user" will fail.  Replacing package 'A' with 
> > package 'B', where package 'B' works totally differently, or performs 
> > different functions than package 'A' will fail because the users will 
> > not use it.

I think here Bob has really nailed what makes deprecation an unworkable 
strategy for these kind of situations. Unless you can stand up an 
absolutely 1-for-1 drop-in replacement, the ecosystem won’t move. And 
we’re talking about pieces of software that took many person-years of 
effort to create. We’re had numerous contributors propose a rewrite in a 
memory safe language and I have (sincerely) wished each of them the best 
of luck, and then never heard from them again. I think we’re all roughly 
on the same page about the desirable end state, but I don’t see this 
kind of deprecation as a strategy that will get us there.

> On 10/23/23 02:54, Demi Marie Obenour wrote:
> > A command-line tool can probably meet all of these requirements but the
> > last one quite easily.  For a library, the difficulty of meeting these
> > requirements will depend significantly on the library API.

Library vs cli is an interesting dimension to this I had not really 
teased out. I agree with you, that sandboxing a library is in some ways 
trickier because you’re doing work on behalf of a caller whose needs you 
don’t statically know.

> On 10/22/23 20:50, Mickaël Salaün wrote:
> > for a Linux fine-grained sandboxing it would be
> > wiser to use the underlying kernel sandboxing feature: Landlock
> > See https://landlock.io/

Thanks for the reminder. I was aware of Landlock, but hadn’t immediately 
connected it with my current task. I’ll go take a look and see what I 
can learn.

Thanks everyone for the comments so far in this thread. Already giving 
me much to think about :)