[PATCH v3 2/8] elf: Add a tunable to control use of tagged memory

[Szabolcs Nagy]

The 11/26/2020 15:48, Richard Earnshaw via Libc-alpha wrote:
> On 26/11/2020 15:27, Siddhesh Poyarekar wrote:
> > On a slightly different but related point, you may want to think about
> > inheritance of the glibc.mem.tagging tunable when you work on v4, i.e.:
> > 
> > 1. Should child processes inherit them?  If you're modeling it along the
> > lines of MALLOC_CHECK_ (i.e. diagnostics only) then you'd want to keep
> > it as default, i.e. no inheritance.  However if you model it as a
> > hardening feature, you may want to set security_level to IGNORE so that
> > children inherit tagging and forking doesn't become a way to escape
> > tagging protections.
> > 
> > 2. Should setxid children inherit enabled memory tagging? Again if
> > you're modeling it as a hardening feature, then maybe you want to set
> > security_level to NONE so that it is inherited by setxid children.  I
> > think it will be the first tunable to cross that boundary if you decide
> > to take that route!
> > 
> 
> A good question.  I'd say at this point it's a bit more of a debugging
> feature (at least until things have settled down); but longer term it
> may well become a hardening feature as well.  Before we can go down that
> route, though we'll need to sort out how to mark binaries that are
> genuinely incompatible with MTE.  We already know that python's object
> management code violates MTE assumptions, for example; either that will
> need to be fixed, or we'll need a route to automatically disable MTE
> when running programs like that.
> 
> So perhaps for now, we'd want to inherit it through normal fork() type
> calls, but perhaps not for setxid at this stage, but we may want to
> widen it later.  On the other hand, for a security feature you'd perhaps
> want a more robust (harder to turn off) mechanism than just modifying a
> user-level environment variable.

fork must inherit it because otherwise existing heap
pointers don't work with free/realloc.

for now i'd ignore the env var for setxid binaries
(though in principle it should be fine: it is supposed
to be a hardenning feature).