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

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 10/05/2023 08:55, Siddhesh Poyarekar wrote:
> On 2023-10-05 04:19, Szabolcs Nagy wrote:
> > i'd fix this in one place that makes the behaviour easy
> > to reason about: _dl_next_ld_env_entry in rtld should
> > just return empty in secure mode and same for getenv,
> > internally it should return empty.
> > 
> > then we know that nothing in libc can depend on the env.
> > (if something parses env directly that should be fixed)
> > 
> > if anything, there should be a whitelist, not blacklist
> > of env vars.
> 
> That won't work because it would require knowledge of (or a mechanism to
> specify) safety of environment variables used by the application and its
> children.  The current unsecvars approach is probably the best option.

why would you need a whitelist of application envvars?

if there is any env var usage *in libc* that is valid to
affect setuid binaries then those should be whitelisted.
(black list works too, but more error prone in imo)

> > of course this changes behaviour, so if we want to be
> > bw compat then we have to live with the current unsetenv
> > logic.
> 
> The current unsetenv logic is well reasoned IMO; the tunables layer made it
> complicated and it ought to be sufficient to just remove that.  But that
> would require dropping the memory tagging tunable from SXID_IGNORE and
> erasing GLIBC_TUNABLES by putting it in unsecvars.h.

i think it is broken to rewrite env[] that is passed by
the kernel. but since glibc always did this i guess it's
fine.