Re: Alternative libio vtable hardening approach

[Florian Weimer <fweimer at redhat dot com>]

On 05/31/2016 09:23 PM, Kees Cook wrote:
> Well, this is certainly better than not having it, and the on/off
> switch isn't in the FILE structure, so I would think this should be of
> a similar protection level. Though, it'd be nice if a process could
> opt-out for its entire lifetime. Right now, any call to _IO_file_init
> disables the protection.

I don't quite see how to do this.  The machine code sequence to set the 
flag has to be in the process image to enable backwards compatibility 
when needed.  It doesn't really matter if this code is in an IFUNC 
handler or in a library subroutine.  And even if we have some 
precondition check (say, the IFUNC handler checks that we are in ld.so 
and relocation processing is running), execution could start after it.

We could have another flag, this time in read-only memory, which is some 
sort of tunable which can be tweaked by the system administrator. 
(Maybe we could even query the SELinux policy engine to get the flag.) 
The fallback path could check this flag as well.

In general, I want to avoid policy-based solutions because I'm told that 
in too many relevant scenarios, only the âanything goesâ policy counts.

Do you think it's import to address this from the start, or can this 
wait until we have a better story for tunables?

> (Also, is the call to _IO_new_file_init in _IO_new_popen wrong? Should
> that be the internal one instead?)

Yes, these parts aren't completely done yet.

I also need to do something about static linking.  The increase in 
executable size appears to be rather moderate, but there are 
linknamespace issues.  I'll try to use weak function symbols for some of 
the methods (particularly the obstack ones), maybe this will help on 
both fronts.

Florian