[devel] [PATCH hasher-priv v1 0/3] Make a daemon from the hasher-priv

[Alexey Tourbin]

On Mon, Dec 16, 2019 at 12:35 PM Dmitry V. Levin <ldv на altlinux.org> wrote:
> On Sun, Dec 15, 2019 at 11:50:13AM +0300, Alexey Tourbin wrote:
> > On Fri, Dec 13, 2019 at 2:42 PM Alex Gladkov <legion на altlinux.ru> wrote:
> > > The hasher-priv is a SUID utility. This is not good. Separation of the
> > > server and client parts will allow us to remove SUID flag.
> >
> > Removing the SUID flag shouldn't be an end in itself. You're still
> > running a process with root privileges which serves user requests.
> > It's the same, except that instead of the SUID flag, the process just
> > starts as root.  So you are not improving privilege separation or
> > something, you are only limiting the ability of the user to tamper
> > with the SUID binary. And tampering with the binary should be
> > pointless anyway (unless glibc is faulty and permits arbitrary code
> > injection, etc.).
>
> While turning a suid root executable into a daemon doesn't automagically
> make everything more secure, it's an important move in the right direction.

Not necessarily. Conversion into a daemon takes more code, which can
have its own faults. Instead of relying on the set-uid mechanism,
you're very likely to up end up with a more complex DIY construction.

> Firstly, the attack surface of a suid root executable is larger than
> of the equivalent root daemon on the other side of a unix domain socket,
> so this change narrows the attack surface.

You are casting doubt on the venerable set-uid mechanism. What if it's
faulty? What if the user can tamper with the binary and somehow inject
arbitrary code? Well, you can do nothing about it, and moreover it's
not your problem. (Likewise, if the kernel is faulty and permits
privilege escalation, you can do nothing about it, and the only way
round is to fix the kernel.) Your basic mechanisms must be secure, and
it's doable. The "attack surface" is just a highbrow way of saying
that the dynamic loader should be insensitive to LD_PRELOAD. :)

> Secondly, this change opens the way for more elaborate privilege separation.
>
> Thirdly, it makes hasher available for PR_SET_NO_NEW_PRIVS'ed
> processes (e.g. self-seccomp'ed) that cannot make use of suid executables.

These might be valid arguments. Still, I find it hard to believe it's
really about security. hasher-priv is minimalistic, and its use is
limited to those few machines that need it, some of them booted over
the network. There is no good reason to believe that we might face any
security risks.