linux-kernel - Re: [PATCH 0/3] Dump command line of faulting process to syslog

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 1 Aug 2022 09:57:56 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     Helge Deller <deller@....de>
Cc:     linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Dump command line of faulting process to syslog

On Mon, Aug 01, 2022 at 05:20:13PM +0200, Helge Deller wrote:
> This patch series allows the arch-specific kernel fault handlers to dump
> in addition to the typical info (IP address, fault type, backtrace and so on)
> the command line of the faulting process.
> 
> The motivation for this patch is that it's sometimes quite hard to find out and
> annoying to not know which program *exactly* faulted when looking at the syslog.
> 
> Some examples from the syslog are:
> 
> On parisc:
>    do_page_fault() command='cc1' type=15 address=0x00000000 in libc-2.33.so[f6abb000+184000]
>    CPU: 1 PID: 13472 Comm: cc1 Tainted: G            E     5.10.133+ #45
>    Hardware name: 9000/785/C8000
> 
> -> We see the "cc1" compiler crashed, but it would be useful to know which file was compiled.
> 
> With this patch series, the kernel now prints in addition:
>    cc1[13472] cmdline: /usr/lib/gcc/hppa-linux-gnu/12/cc1 -quiet @/tmp/ccRkFSfY -imultilib . -imultiarch hppa-linux-gnu -D USE_MINIINTERPRETER -D NO_REGS -D _HPUX_SOURCE -D NOSMP -D THREADED_RTS -include /build/ghc/ghc-9.0.2/includes/dist-install/build/ghcversion.h -iquote compiler/GHC/Iface -quiet -dumpdir /tmp/ghc13413_0/ -dumpbase ghc_5.hc -dumpbase-ext .hc -O -Wimplicit -fno-PIC -fwrapv -fno-builtin -fno-strict-aliasing -o /tmp/ghc13413_0/ghc_5.s
> 
> -> now we know that cc1 crashed while compiling some haskell code.

This does seem really useful for debugging.

However, it's also an information disclosure in various ways. The
arguments of a program are often more sensitive than the name, and logs
have a tendency to end up in various places, such as bug reports.

An example of how this can be an issue:
- You receive an email or other message with a sensitive link to follow
- You open the link, which launches `firefox https://...`
- You continue browsing from that window
- Firefox crashes (and recovers and restarts, so you don't think
  anything of it)
- Later, you report a bug on a different piece of software, and the bug
  reporting process includes a copy of the kernel log

I am *not* saying that we shouldn't do this; it seems quite helpful.
However, I think we need to arrange to treat this as sensitive
information, similar to kptr_restrict. (It would also be helpful if
there was a way to tell `dmesg` "please give me the redacted version of
the log", and bug reporting software used that by default.)

- Josh Triplett