linux-kernel - Re: [RFC] [PATCH] sysctl for the latecomers

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 for Android: free password hash cracker in your pocket

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

Message-Id: <200608021456.k72EujBt007376@laptop13.inf.utfsm.cl>
Date:	Wed, 02 Aug 2006 10:56:45 -0400
From:	"Horst H. von Brand" <vonbrand@....utfsm.cl>
To:	Chase Venters <chase.venters@...entec.com>
cc:	Amit Gud <agud@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] sysctl for the latecomers 

Chase Venters <chase.venters@...entec.com> wrote:
> On Tue, 1 Aug 2006, Chase Venters wrote:
> > On Tue, 1 Aug 2006, Amit Gud wrote:
> >>  /etc/sysctl.conf values are of no use to kernel modules that are inserted
> >>  after init scripts call sysctl for the values in /etc/sysctl.conf
> >>
> >>  For modules to use the values stored in the file /etc/sysctl.conf, sysctl
> >>  kernel code can keep record of 'limited' values, for sysctl entries which
> >>  haven't been registered yet. During registration, sysctl code can check
> >>  against the stored values and call the appropriate strategy and
> >>  proc_handler routines if a match is found.
> >>
> >> Attached patch does just that. This patch is NOT tested and is just to
> >> get opinions, if something like this is a right way of addressing this
> >> problem.

> > Do you anticipate any users that you could list? It seems like a
> > more appropriate approach would be to allow some kind of user-space
> > hook or event notification to run upon module insertion, which could
> > then apply the appropriate sysctl.

> Btw, wanted to add some comments on the specific approach:
> 
> 1. A ring hard-coded to 32 elements is IMO unuseable. While it may not
> be a real limit for what use case you have in mind, if it's in the
> kernel sooner or later someone else is going to use it and get
> bitten. Imagine if they wrote in 33 entries, and the first one was
> some critical security setting that ended up getting silently
> ignored...

Right.

> 2. On the other hand, allowing it to grow unbounded is equally
> unacceptable without a mechanism to list and clear the current
> "pending" sysctl values. Unfortunately, at this point, you're starting
> to violate "KISS".

Yep.

> Are the modules you refer to inserted during init at all? Because it
> seems like it would be a lot more appropriate to just move sysctl
> until after loading the modules, or perhaps running it again once they
> are loaded.

OK, lets step back a bit... sysctl(8) can be used to load other values, or
to change them, etc. Whatever is in sysctl.conf is just /default/ values,
/typically/ set on boot. You could let the initscripts set those, then
fiddle them by hand. If a module is now inserted, you can't just reset the
values to the ones in the file.

Perhaps module-specific values should be set in the configuration for the
module itself (i.e., arguments) or add to modprobe.conf something along
the lines:

  sysctl mymod kernel.mystuff=42

and have modprobe(8) run sysctl(8) as needed after loading the module? 
Sounds more KISSy to me...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/