[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
