Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 23 Oct 2023 17:33:31 +1100
From: Matthew Fernandez <>
Subject: Re: sandboxing,of upstream programs by distros

> 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

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 :)

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.