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

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

The 10/04/2023 07:59, Siddhesh Poyarekar wrote:
> On 2023-10-04 03:29, Szabolcs Nagy wrote:
> > The 10/03/2023 16:11, Siddhesh Poyarekar wrote:
> > > Limit effect of memory tagging to the same process and don't let it
> > > bleed across privilege boundaries into non-setuid children of setuid
> > > processes.
> > > 
> > > Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
> > 
> > the description does not match the documented behaviour of
> > SXID_IGNORE. (the setuid binary passes on the setting from
> > its parent, i don't see the privilege boundary crossing)
> 
> Maybe "privilege boundary crossing" is too strong a phrase, how about "bleed
> across different users or groups"?
> 
> > and it does not explain why would you want to turn a security
> > hardening feature off.
> > 
> > i'm not against the patch as the heap tagging feature is
> > very experimental at this point, but it needs a better
> > explanation.
> 
> How about:
> 
> """
> Memory tagging is still an experimental feature, so limit propagation of
> tunables across setxid binaries.
> """

well i don't mind the wording, but i wanted to see
an actual justification.

"this is experiemental" is not useful.

"limit propagation across setxid binaries" answers
what the patch does, but not why.

is there an actual problem you are trying to solve?
do you think SXID_IGNORE is not suitable for security
hardening features? what is the intended usage of it?

i don't see anything immediately wrong with inheriting
env from a grandparent process if in between there was
a setuid process that ignored the env. (i also don't
see it as very useful/necessary)

> In future though, would you want SXID_IGNORE for memory tagging?  I would
> expect that once memory tagging becomes a stable feature you'd want it to be
> enabled by default and disabled by, e.g. a systemwide tunable.  I can't see
> why you'd want it to go across the setxid boundary.

it may not be enabled by default because of its overhead
(we need hw to decide).

i think it is unexpected that setxid drops env vars
(ignoring is ok, but dropping is weird).

i can live with the 'drop' semantics but then why do
we have SXID_IGNORE?