Re: Alternative libio vtable hardening approach

[Kees Cook <keescook at chromium dot org>]

On Wed, Jun 1, 2016 at 1:56 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.

Right, totally agreed. I guess I'm not clear on the execution order of
some of these things. How early in the process lifetime can glibc know
that it must use the compat logic? Is it early enough that the dynamic
linker can decide and write the result into what-will-be-read-only
memory?

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

I think it can be secondary. The value is separate from the FILE
table, so I'm happy with that.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security