Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i83e94755:Fastmail
Date:   Thu, 4 Aug 2022 02:06:38 -0700
From:   Josh Triplett <josh@joshtriplett.org>
To:     Helge Deller <deller@gmx.de>
Cc:     linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Dump command line of faulting process to syslog
Message-ID: <YuuMHkMIssKcBYeX@localhost>
References: <20220801152016.36498-1-deller@gmx.de>
 <YugGFEjJvIwzifq7@localhost>
 <a0bf15a2-2f9c-5603-3adb-ffa705572a92@gmx.de>
 <Yut+0Fg7F99MI48J@localhost>
 <2f4c1abb-ca27-178a-31c3-5e422613e7e8@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2f4c1abb-ca27-178a-31c3-5e422613e7e8@gmx.de>
Precedence: bulk

On Thu, Aug 04, 2022 at 10:39:52AM +0200, Helge Deller wrote:
> On 8/4/22 10:09, Josh Triplett wrote:
> > On Tue, Aug 02, 2022 at 09:40:50PM +0200, Helge Deller wrote:
> >> On 8/1/22 18:57, Josh Triplett wrote:
> >>> 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 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.)
> 
> I'm fine with kptr_restrict, but I'm puzzled for which value of kptr_restrict
> the command line should be shown then.
> By looking at the meaning of kptr_restrict, I think the command line should be
> hidden for values 0-2.
> Do you suggest to add a new value "3" or am I missing something?

I'm suggesting treating it the same as a pointer value:

0: always show command line
1: show command line if read by privileged caller
2: never show command line

That could either use kptr_restrict or use a separate cmdline_restrict.