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

[Josh Triplett]

On Tue, Aug 02, 2022 at 09:40:50PM +0200, Helge Deller wrote:
> On 8/1/22 18:57, Josh Triplett wrote:
> > 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.
> 
> Yes.
> 
> > 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
> 
> Yes, that's a possible way how such information can leak.
> 
> > 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.
> 
> I wonder what the best solution could be.
> 
> A somewhat trivial solution is to combine it with the dmesg_restrict sysctl, e.g.:
> 
> * When ``dmesg_restrict`` is set to 0 there are no restrictions for users to read
> dmesg. In this case my patch would limit the information (based on example above):
>     cc1[13472] cmdline: /usr/lib/gcc/hppa-linux-gnu/12/cc1 [note: other parameters hidden due to dmesg_restrict=0 sysctl]
> So it would show the full argv[0] with a hint that people would need to change dmesg_restrict.
> 
> * When ``dmesg_restrict`` is set to 1, users must have ``CAP_SYSLOG`` to use dmesg(8)
> and the patch could output all parameters:
>      cc1[13472] cmdline: /usr/lib/gcc/hppa-linux-gnu/12/cc1 -quiet @/tmp/ccRkFSfY -imultilib . -imultiarch hppa-linux-gnu ....
> 
> That would of course still leave few possible corner-cases where information
> could leak, but since usually programs shouldn't crash and that
> people usually shouldn't put sensitive information into the parameter
> list directly, it's somewhat unlikely to happen.
> 
> Another different solution would be to add another sysctl.
> 
> Any other ideas?

I don't think we should overload the meaning of dmesg_restrict. But
overloading kptr_restrict seems reasonable to me. (Including respecting
kptr_restrict==2 by not showing this at all.)