linux-kernel - Re: Does vdso_install attempt to re-compile objects under root privilege?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Apr 2019 16:38:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>, X86 ML <x86@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Does vdso_install attempt to re-compile objects under root privilege?

On Tue, Apr 23, 2019 at 11:47 AM Andy Lutomirski <luto@...nel.org> wrote:
>
> Hmm.  I suppose an alternative would be for vdso_install to fail if
> the vdso isn't built?

I absolutely abhor even the concept of building the kernel as root,
and I think it should be actively disallowed. Our build system is
good, but it's good as in "clever and complex" rather than necessarily
good as in "very secure".

So anybody who builds the kernel as root is doing something seriously
wrong, in my opinion.

That's partly exactly _because_ we have a lot of magical and very
powerful build rules, and complicated implicit things going on.

For example, our dependencies aren't even about just the files in the
kernel repository itself, we have clever things like "if the compiler
has been updated and features or version changes, we'll automatically
rebuild, because it's part of our clever build system checks".

But that is also part of the reason why I absolutely do *not* want any
root-building to happen, because our build setup is simply way too
clever.

If root builds stuff, you'll end up with root-owned generated
subdirectories or various config files etc, and even if you don't have
security issues, it can complicate the build later as a regular user.

I've had the build occasionally fail in odd ways, because some
root-owned file was now no longer removable (usually it's the
auto-generated header files in the directory, and the root-generated
and owned directory is now not writable by the developer any more).
And every time it happens, I shudder.

So all of that simply boils down to "root should not be running those
complex rules for our config and dependency magic".

At the same time, "make install" obviously needs to be done as root.

All of which is why I opine that "make install" should never build
anything at all, it should purely be used as a "install previously
built files".

So yes, I'd much prefer just failing over trying to build as root (or
even trying to figure out dependencies as root).

> What's the ideal outcome here?

I'd basically like the rule for "make install" to be that it never
ever generates a single file in the build tree, so that there are
never any root-owned (or root-overwritten) files there.

So "make install" should even avoid all dependency checking, for the
simple reason that if you happen to do a system update between "make"
and "make install", our smart dependencies should never say "oh, the
compiler version has changed, so now I'll rebuild everything as root
just because 'make install'".

So I think the ideal outcome is just "fail if you can't find the files
to install".

                     Linus