Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

[Willy Tarreau]

On Thu, Jan 11, 2018 at 10:35:57AM -0800, Dave Hansen wrote:
> On 01/11/2018 07:44 AM, Willy Tarreau wrote:
> >> 4. Cleared on setuid() and friends
> > This one causes me a problem : some daemons already take care of dropping
> > privileges after the initial fork() for the sake of security. Haproxy
> > typically does this at boot :
> > 
> >    - parse config
> >    - chroot to /var/empty
> >    - setuid(dedicated_uid)
> >    - fork()
> 
> This makes me a _bit_ nervous.  I think Andy touched on this, but I'll
> say it another way: you want PTI turned off because you trust an app to
> be good, but you also drop permissions because it is exposed to an
> environment where you do *not* fully trust it.
> 
> I'm not sure how you reconcile that.
> 
> If your proxy gets compromised, and pti is turned off, you are entirely
> exposed to meltdown from that process.

Yes but security is not either black or white, it's about adding protections
that make sense wherever possible. Meltdown would "only" allow you to dump
the system's memory. Running as root would additionally allow you to modify
this memory, ptrace processes outside of the chroot to inject backdoors etc.

For me, and for a lot of users I guess, the choice is easily made.

> I don't know exactly what you
> are doing, but isn't this proxy sitting there shuffling untrusted user
> data around all day?

Yes definitely for some users, while it can be very trusted data for others.
For example those dealing with wire transfers have much more to care about
than someone reading their kernel memory when they can also read and modify
the amount of money in the transfers if they want!

And it has to do all this *fast*, that's one of its most touted qualities.
And that's even why people who care the most about performance always
install it on Linux because today it's the best OS for this job.

Again Dave, it's a tradeoff. People using such components generally know
what they are doing and are the ones to decide. Some of them prefer to run
as root because it allows them to bind to foreign addresses, others cannot
start as root because the local policy is strict about this, some do a lot
of things some of us would consider ugly but which are critical to their
acitvity. It's not up to me as the software's author nor to us as system
developers to tell our users how they will be much slower to be more
secure if they decide that they don't care about this *specific* risk.
Our job is to properly protect those who don't know they're at risk and
to help the other ones reduce the risk to the minimum needed for a given
task.

In this case the minimum can be pretty well summarized :
  - PTI on by default on the system
  - no PTI for the performance-sensitive process if the admin decides it
  - switch to a harmless uid/gid couple once not needed to be root anymore
  - if the process may execute external processes, give it an option to
    disable PTI before or during execve() to avoid exposing the system to
    what they could be doing.

I think that's pretty reasonable for a normal production environment.

Willy