Subject: cloning loopback and security [was Re: CVS commit: src/sys ]
To: None <,>
From: Jonathan Stone <>
List: tech-kern
Date: 12/08/2004 15:06:47
Reposting some offlist discussion, trying to think constructively
about the lo-cloning/lo0ifp issues:

What about adding a sysctl that prohibits cloning more than 1 loopback
device, or (if there's already more than 1) cloning further devices?
If the sysctl value is nonmodifiable at securelevel > 0, I think
that'll meet most of my concerns.

Just personally, thinking just about loopback devices, I'd prefer an
optional config-time option, which gives those who care the ability to
set an config-time-confiugrable upper bound on the number of loopback
instances. If the config-time option isn't set, there's no explicit
limit. Would anyone actively object to an optional option which
implements that?

Also, based on other recent conversation re devfs and hardened
systems, I think there's a good case for forbidding all device
attachment and creation at securelevel > 0. So we'll have _some_ tests
for denying cloning.  Whether or not to implement optional upper
bounds for cloning devices (which can drop into the same codepoints as
the securelevel checks) is an open question. This is the right place
to ask it.

Christos: whats your take? Anyone else's?