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

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 2023-10-04 10:04, Szabolcs Nagy wrote:
> 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)

The actual problem I'm trying to solve is to get rid of SXID_IGNORE and 
SXID_NONE and the first step is to drop users of those levels. 
Supporting those levels requires additional processing in 
__libc_enable_secure, which is a source of bugs like CVE-2023-4911.  I'm 
not convinced that we really *need* to have tunables go across sxid 
boundaries, so I want to flip the question around: do you think it is 
*necessary* for memory tagging tunables to percolate sxid boundaries? 
If not, then they should stay at SXID_ERASE.

>> 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?

They were introduced for compatibility with the original semantics of 
MALLOC_MMAP_THRESHOLD_ and friends, that would go across sxid 
boundaries.  In those cases too I'm not convinced that the use case 
really needs to be supported and that users should find a way to achieve 
that effect in other ways, such as having a wrapper around the 
non-setuid child that needs to see these tunables and export the 
tunables in that wrapper.

The end goal here is to drop everything but SXID_ERASE so that we don't 
have to do string twiddling under __libc_enable_secure.

The other alternative to achieve the same effect (i.e. not twiddle 
strings in __libc_enable_secure) could be to make *everything* 
SXID_IGNORE, which would then leave GLIBC_TUNABLES untouched for 
non-setuid children to do what they please with it.

Sid