* Willy Tarreau <w...@1wt.eu> wrote:
> On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
> >
> > * Borislav Petkov <b...@alien8.de> wrote:
> >
> > > Oh, and you've built the kernel with the option to be able to disable
> > > PTI so it's not like you haven't seen it already.
> >
> > In general in many corporate environments requiring kernel reboots or
> > kernel
> > rebuilds limits the real-world usability of any kernel feature we offer
> > down to
> > "non-existent". Saying "build your own kernel or reboot" is excluding a
> > large
> > subset of our real-world users.
> >
> > Build and boot options are fine for developers and testing. Otherwise
> > _everything_
> > not readily accessible when your distro kernel has booted up is essentially
> > behind
> > a usability (and corporate policy) wall so steep that it's essentially
> > non-existent to many users.
> >
> > So either we make this properly sysctl (and/or prctl) controllable, or just
> > don't
> > do it at all.
>
> After having slept over it, I really prefer the sysctl+prctl approach.
> It's much more consistent with the rest of the tunables which act
> similarly. We have mmap_min_addr, mmap_rnd_bits, randomize_va_space, etc
> All of them are here to trade some protections for something else (mostly
> compatibility).
>
> What I'd like to have would be a sysctl with 3 values :
> - 0 : default disabled : arch_prctl() fails, this is the default
> - 1 : forced enabled : arch_prctl() succeeds for CAP_SYS_RAWIO
> - -1 : permanently disabled : fails and cannot be switched back to enabled.
Btw., I wouldn't call the value of 1 'forced enabled', it's simply enabled.
BTW., we might eventually also want to introduce a 'super flag' for all the
permanent disabling features, so that sysadmins/distros who want to default to
restrictive policies can set that and don't have to be aware of new tunables,
and
this also protects against renames, etc.
Thanks,
Ingo
