[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231022000649.GA14340@openwall.com>
Date: Sun, 22 Oct 2023 02:06:49 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: sandboxing,of upstream programs by distros
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.
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.)
Speaking of pledge() for Linux, there's this project by Justine Tunney:
https://justine.lol/pledge/
https://github.com/jart/cosmopolitan/blob/master/libc/calls/pledge-linux.c
This is part of Justine's libc implementation, but a comment says:
* This file contains only the minimum amount of Linux-specific code
* that's necessary to get a pledge() policy installed. This file is
* designed to not use static or tls memory or libc depnedencies, so
* it can be transplanted into codebases and injected into programs.
Are there already other projects using this? Any distros offering it?
> To step this out a bit... we have a large, old code base that was written
> decades prior to current best practices. It has numerous known memory
> safety issues and ever-dwindling maintainer capacity. It is also a
> dependency, either directly or indirectly, of a significant fraction of
> the world's software. I am guessing this scenario sounds uncomfortably
> familiar/common to many on this list.
>
> We (the maintainers) have discussed sandboxing as a way of mitigating
> the risk of known bugs. However, one of the problems is that we don't
> know the complete set of required privileges of our dependencies. The
> software can be configured with or without various libraries and also
> has a plugin mechanism for dynamic code loading. Basically if a
> sandboxing solution like seccomp wants to know our full set of system
> calls, we ourselves don't know it.
With pledge(), you could provide coarse-grained "promises" rather than
constrain yourself to individual syscalls. Maybe that would work for
you? However, it'd only be reliably used by packages if those introduce
a build-time dependency on whatever package provides pledge(). So e.g.
if we add a package providing pledge() in Rocky Linux Security SIG repo,
that won't be picked up by my example packages above built as part of
EPEL (not part of Rocky Linux project) or AppStream (part of the
project, but currently unlikely to be overridden in the SIG).
OTOH, you could even integrate the pledge-linux.c file in your project,
in which case it could become a standard feature used by many Linux
distros and extra package repos once they update to your newer version.
> The downstream maintainer packaging the software for, e.g. Rocky, does
> though. They have a complete picture of which libraries/features are
> enabled and how locked down the plugin stuff is.
>
> So, where I'm going with this, is that if the various packaging
> ecosystems could (or do) offer sandboxing to upstream, people like us
> would gladly opt in to it. Of course, these downstream maintainers can
> already seccomp our software today. But expecting them to reverse
> engineer our exact needs seems a bit much.
I find the above two paragraphs somewhat contradictory - the downstream
maintainer packaging the software does have technical ability to figure
out the exact set of syscalls the software will use on their distro with
current versions of other packages, but OTOH "expecting them to reverse
engineer our exact needs seems a bit much." I'd say that figuring out
that exact set _is_ this kind of reverse-engineering, and is too much to
expect from a typical package maintainer, who is not focusing on just
this one package. Besides, the exact set of syscalls may also change as
other packages get updated; this is not something guaranteed to stay
stable within what's normally considered a stable ABI. So that person
would also need to identify and introduce extra explicit package version
dependencies, and to do extra package rebuilds to keep those satisfied.
Maybe a coarse-grained pledge() would make this more realistic, or not.
Alexander
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.
