linux-kernel - Re: [PATCH] trace/uprobes: fix output issue with address randomization

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:   Mon, 18 Dec 2017 10:16:04 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thomas Richter <tmricht@...ux.vnet.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Hendrik Brueckner <brueckner@...ux.vnet.ibm.com>,
        "Tobin C. Harding" <me@...in.cc>
Subject: Re: [PATCH] trace/uprobes: fix output issue with address randomization

On Mon, Dec 18, 2017 at 9:59 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Hmm, since the scrambling of %p is to prevent kernel addresses from
> leaking, I wonder if it would be OK to make it only scramble the address
> if the address is a kernel address. It should be fine to print user
> space addresses unscrambled. Shouldn't it?

So %p itself shouldn't have logic like that, because some of those
addresses can be sensitive even if they aren't strictly kernel
addresses.

For example, anything that prints out sensitive physical addresses
wouldn't look like a kernel virtual address, but it could still expose
very sensitive data.

So that check would have to be done by the user of %p, not by %p itself.

So generally, the fix for "oops %p hashing now breaks xyz" should
generally be to make sure that the protections are correct, and then
it can be turned into %px (when it can't just be removed).

In this particular case, we already have the magical case of "don't
print (null)", and I think _that_ the case that could be just extended
to say "don't print sensitive data" and then the %p can be changed
into a %px.

So one approach would be to simply checking (at _open_ time, not at IO
time! That was one of the things that I absolutely detested about %pK
- getting that fundamentally wrong) whether the opener could write a
kernel address to the file, and if the opener has those permissions,
then it obviously can read the values too.

But in this case I would suggest just making "uprobe_events" be 0600
rather than 0644. Why the hell should a normal user be able to read
whatever events that root has set?

Same goes for  "uprobe_profile". Is it really sensible that anybody
can read that file? It sounds insane to me. Why should a random
regular user be able to see what probes are installed?

Honestly, very few of the "let's just change %p to %px" has been
correct. There is pretty much _always_ some permission problem or
other that says "hell no, that data should not have been so widely
available before".

The only time a pure %p -> %px is warranted is likely for oops reports
etc. We did have a couple of those.

                Linus