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.
