Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE

["Zack Weinberg" <zack@owlfolio.org>]

On Sun, Oct 8, 2023, at 3:51 PM, Michael Hudson-Doyle wrote:
> On Fri, 6 Oct 2023 at 07:32, Zack Weinberg <zack@owlfolio.org> wrote:
>> I also think we ought to be talking about a very short *whitelist* of
>> environment variables that are allowed to survive execve() of a
>> setxid binary -- off the top of my head, TERM, LANG, LANGUAGE, LC_*,
>> and maybe *nothing else* -- and putting that list into the kernel
>> itself.
>
> That would break at least one application I know about (snapd):
> https://bugs.launchpad.net/snapd/+bug/1682308

Flip answer: I don't think snapd ought to exist in the first place
(because it violates the Highlander Principle of Package Management),
so I don't care if it gets broken.

More serious answer: The specific thing snapd is doing here could be
handled via some sort of client-server protocol, with a *non*-setxid
client.  This would allow the code running at elevated privilege to
treat the environment variables as an opaque blob of data to be copied
into the nascent sandboxed process, which would be safer.

Complementary serious answer: Are you sure there's no way to leverage
the ability to set arbitrary environment variables inside the sandbox
to carry out a sandbox escape?  Are you *certain*?

zw