[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] sandboxing,of upstream programs by distros
From:       Matthew Fernandez <matthew.fernandez () gmail ! com>
Date:       2023-10-23 6:33:31
Message-ID: c15f3a69-2ded-7343-4f6c-51fc5d83a956 () gmail ! com
[Download RAW message or body]

> 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 :)
[prev in list] [next in list] [prev in thread] [next in thread]