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.