linux-kernel - Re: [PATCH] reboot: disable usermodehelper to prevent fs access

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <BANLkTimgGxM78w4nAsde+haaGh9GjHGNyg@mail.gmail.com>
Date:	Fri, 6 May 2011 03:07:25 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Valdis.Kletnieks@...edu
Cc:	Greg KH <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] reboot: disable usermodehelper to prevent fs access

On Fri, May 6, 2011 at 02:04,  <Valdis.Kletnieks@...edu> wrote:
> On Thu, 05 May 2011 14:34:58 PDT, Greg KH said:
>> On Thu, May 05, 2011 at 05:24:25PM -0400, Valdis.Kletnieks@...edu wrote:
>> > On Thu, 05 May 2011 13:32:05 +0200, Kay Sievers said:
>> > > In case CONFIG_UEVENT_HELPER_PATH is not set to "", which it
>> > > should be on every system
>> >
>> > If it indeed should be that on every system, shouldn't it be listed
>> > in feature-removal-schedule.txt?

Systems _very_ limited in scope might still want to use it, or it
theory it might be useful for debugging. On usual boxes it's nothing
but trouble, and on limited RAM boxes it's very a simple way to go
straight to OOM instead of booting up.

>> It's the default value, but distros, and people, can and do override it
>> for various reasons.  Why would it be added to
>> feature-removal-schedule.txt?

Yeah, nothing to remove really, someone could kill it from defconfig
though. I don't know what defconfig is really good for, and what are
the rules here, or why it's still in there.

> Well, what Kay said was "it should be on *every* system", making it sound like
> it's an option past its shelf life.  Certainly, "the default should be null for
> the vast majority of systems" is a different scenario.

The default is "" since quite a while. Just the archs defconfig might
not follow.

>> > Does anybody have a running list of "Stuff we set by default at one time, but
>> > no longer recommend"?

Nothing really at that scale. Running a binary from the kernel for
every event is really nothing we ever want to do these days.

>> Look at the default values for different configurations options and why
>> they differ in your system is about the only way that I know of, sorry.
>
> Hmm.. I suspect diffconfig will only get me part of the way there.  Maybe what
> I *need* to do is find a 2.6.25-ish x86_64 defconfig, the current one, diff those, and
> then see what changed (as opposed to truly new config flags), and then see
> how many of those changes do/don't show up in *my* config as well..
>
> Maybe that would be a good project for some #kernelnewbie to look at ;)
> "In my copious free time" ;)

Sure, sounds good. :)

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/