[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Oct 2023 20:45:40 -0400
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Subject: Re: sandboxing,of upstream programs by distros
On Sun, Oct 22, 2023 at 02:06:49AM +0200, Solar Designer wrote:
> Hi Matt,
>
> I'm sorry I didn't follow up on this sooner.
>
> On Sat, Oct 14, 2023 at 06:39:49PM +1100, Matthew Fernandez wrote:
> > Is there interest/solutions within the Rock Security SIG or other
> > distro's security teams for sandboxing that package upstreams can opt
> > into?
>
> For Rocky Linux Security SIG, the only relevant thing mentioned so far
> was possibly offering an OpenBSD pledge()-alike that other packages
> could use. However, I am skeptical any actually would, unless we also
> introduce such uses ourselves and maintain own "override" packages
> (replacing RHEL rebuild ones or those coming from EPEL, etc.) of such
> software. 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.
Has deprecating ImageMagick and/or GraphicsMagick outright been
considered? I don’t just mean the downstream packages, but the entire
upstream projects, or at least the libraries.
> Also, continuing these examples, it's probably more realistic to sandbox
> their command-line tools, whereas the underlying libraries are probably
> more exposed via language bindings. Would we be introducing creation of
> child processes into the libraries? That's tricky as it could violate
> expectations of programs using such libraries. (Yet at Openwall we did
> a similar thing in pam_tcb, albeit limiting this maybe-unexpected
> behavior to setups that opted-in to it with the "fork" option in the PAM
> configuration file. So it's not completely out of consideration.)
One option would be to instead make an IPC call to a persistent daemon
running in the background. 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 of 4x or more (like SoftBound+CETS did).
Stuff that cares about performance should be migrating to something like
libvips or ImageFlow.
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
