[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c15f3a69-2ded-7343-4f6c-51fc5d83a956@gmail.com>
Date: Mon, 23 Oct 2023 17:33:31 +1100
From: Matthew Fernandez <matthew.fernandez@...il.com>
To: oss-security@...ts.openwall.com
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 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 :)
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.
