Subject: Re: cloning loopback and security [was Re: CVS commit: src/sys ]
To: James Chacon <jmc@NetBSD.org>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 12/09/2004 13:05:30
In message <20041209204623.GA17032@netbsd.org>, James Chacon writes
>On Thu, Dec 09, 2004 at 03:39:50PM -0500, Nathan J. Williams wrote:
>> It seems that the "hardened system" approach you discuss prefers
>> everything to be wired down and as little as possible to be
>> configurable at run-time.
Yes. Fair comment.
>> However, the general trend of development is for increased runtime
>> configurability and flexibility (reflecting, among other things, the
>> larger variety and hot-swap ability of modern hardware and
>> It's not obvious to me that it makes sense, or will continue to make
>> sense, to try to accomodate both of these ideals in the same system.
I very much hope we can acommodate both.
>> I'm not really sure what conclusion to draw from this, but I think the
>> general issue needs discussing. The continued proliferation of "make
>> more flexible, but add an option somewhere to rigidize" changes is
>> very unwieldly in implementation, documentation, and testing.
I don't necessarily buy that; see below. I'm also interested to see
Thor's response, once he's finished finals &.c
>I agree here which is why I think a sysctl option to tighten it down
>is perfectly acceptable for those who don't want certain cloning type
>devices to be able to instantiate infinite instances.
>But...if that's there we don't also need to add in code to hardcode the
>same thing at compile time.
Christos seems to've agreed to optional limits of some kind. Matt
Thomas strongly encouraged me to suggest the idea here. That's at
least the beginning of a consensus. Though I appreciate where you
(Nate and James) are coming from, too.
I think my further claim is: if we do the sysctl hooks with sufficient
discipline and abstraction (e.g., via macros with highly stylized
naming rules), -- which I think is a good ideda in itself, for
uniformity and maintainability and documentation and so on -- then the
config/compile-time controls can be added at negligible marginal cost.
>If we're gonna do that, then the logic would
>assume we'd be doing that for all dynamic type variables done today via
>sysctl and the movement has been away from that. A sysctl is "good enough"
>as it can be controlled directly at startup time and then move security
>level up to whatever point you want. [...]
Except if you ever want to upgrade, then you may need to lower
securelevel. That can get ... exceedingly tricky.