Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.GSO.2.20.2310221118590.6992@scrappy.simplesystems.org>
Date: Sun, 22 Oct 2023 11:26:25 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
To: oss-security@...ts.openwall.com
Subject: Re: sandboxing,of upstream programs by distros

On Sun, 22 Oct 2023, Demi Marie Obenour wrote:

>> Unfortunately, most Linux IPC mechanisms are not very secure since they rely
>> on historical Unix privilege models to control access.
>
> If one can bypass access control on IPC, one can easily get root by
> sending malicious commands to systemd, so I don't think this is
> something to worry about.

Looking at the 5 rules you posted, my concern is addressed by rule #2 
(I/O resources opened in advance).

> 2. All I/O resources (such as file descriptors) must be acquired before
>   processing untrusted input.  It must not be possible to use these
>   resources to access additional resources the program should not have
>   access to.

This request seems the most challenging to satisfy.

> 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.  I am not
> familiar with the GraphicsMagick API and so am not sure how difficult it
> will be for the GraphicsMagick API to support sandboxing.

A different I/O interface module would need to be developed to support 
the possibility of opening an output descriptor in advance.

If one looks at ImageMagick, VIPS, GraphicsMagick, etc., one will 
quickly see that those implementations optionally depend on tens of 
other implementations.  For example, VIPS normally links with 
ImageMagick or GraphicsMagick.  So many important programs have 
complex dependencies.

It is common for temporary files to be created and so this issue would 
need to be addressed.

Bob
-- 
Bob Friesenhahn
bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

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.