Message-ID: <a0bf15a2-2f9c-5603-3adb-ffa705572a92@gmx.de>
Date:   Tue, 2 Aug 2022 21:40:50 +0200
From:   Helge Deller <deller@....de>
To:     Josh Triplett <josh@...htriplett.org>
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 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?

Helge

Powered by blists - more mailing lists