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

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

Date:	Tue, 1 Aug 2006 15:36:07 -0500 (CDT)
From:	Chase Venters <chase.venters@...entec.com>
To:	Amit Gud <agud@...hat.com>
cc:	Chase Venters <chase.venters@...entec.com>,
	linux-kernel@...r.kernel.org, hpa@...or.com, deweerdt@...e.fr
Subject: Re: [RFC] [PATCH] sysctl for the latecomers

On Tue, 1 Aug 2006, Amit Gud wrote:

> Chase Venters wrote:
>>  On Tue, 1 Aug 2006, Chase Venters wrote:
>>  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...
>>
>>  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".
>> 
>
> You figured it right, theres no "correct" number of elements that I could 
> adhere to.
>
>>  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.
>> 
>
> I have a case where sunrpc module gets inserted and 
> sunrpc.tcp_slot_table_entries parameter is to be set _before_ nfs module is 
> inserted. I agree that for this particular case user-space works (either udev 
> rule, or modprobe.conf or sysctl after modprobe in initscripts), but am on a 
> lookout for a more generic way for handling such cases - be it user-space or 
> otherwise.

It just seems like something that belongs in user-space -- whether that be 
better init scripts, changes to modprobe, both, or something else 
entirely.

To make a kernel implementation of this concept that isn't 
fundamentally flawed from a usability and "least-surprise" 
perspective would mean enough code and behavior that the resulting 
implementation wouldn't be considered correct for the kernel anyway.

The kernel has, fundamentally, three kinds of configuration - CONFIG_*, 
the bootloader command-line, and 'live' configuration that gets set by 
user-space whenever appropriate.

>
> AG
>

Thanks,
Chase
-
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/