[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5492404f-bfed-d812-85b5-a871d46e1a79@gmail.com>
Date: Sun, 15 Oct 2023 07:52:07 +1100
From: Matthew Fernandez <matthew.fernandez@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: sandboxing,of upstream programs by distros
On 10/15/23 04:07, Demi Marie Obenour wrote:
>
> Which software is this? Are there plans to at least fix the known
> memory safety problems? If not, I think it would be best to disable the
> known-vulnerable features by default. If the entire software package is
> vulnerable, I recommend deprecating it and recommending that downstream
> users migrate to a more secure alternative.
I deliberately did not name it to avoid getting into a discussion like
this. The short answer is that we’re doing our best but the history of
the project includes 10+ year old bugs that no one has had the time or
resources to address. “fix all the bugs” simply is not a strategy that
survives contact with the real world.
> You have to be willing to break compatibility to at least some degree.
> If you try to support everything, you wind up with something like Qubes
> OS’s “convert to trusted image”, which creates and destroys an entire
> virtual machine for every operation. Even then, you will still break
> a (hypothetical) plugin that accesses the Internet, because that VM
> should not have network access.
>
> What I would do is compile a list of system calls that are reasonable to
> make after startup. Once all plugins have been loaded and all
> configuration files have been read, no plugin should be opening files or
> making network connections. If it does, that plugin is broken and needs
> to be fixed. You can have these system calls fail rather than killing
> the entire process, but you cannot try to support arbitrary plugins.
> That said, I expect most existing plugins will work fine with
> sandboxing.
Sure, but you’re answering a different question than the one I asked.
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.
