Re: sandboxing,of upstream programs by distros

[Bob Friesenhahn <bfriesen () simple dallas tx us>]

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 () simple 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