CC'ed to kre and Charles. I think we've all been genuinely talking
past each other, and that text below should clear that up.  Also,
anyone took insult from my asking whether people were for real or
playing dumb, or for words like "obtuse": I hope this clears that up
too, and I apologise for any unintended offense.

In message <20041208233638.E68122AC7A@beowulf.gw.com>,
Christos Zoulas writes:

>On Dec 8,  3:06pm, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
>-- Subject: cloning loopback and security [was Re: CVS commit: src/sys ]
>
>| 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.
>
>I undestand the desire to have cloning controlled, but why only for
>the loopback? What is the security issue with the additional loopback,
>as opposed for let's say gif, or ppp, or tun? How is loopback special?

Loopback is special because it is special. It's not really an option:
if you have INET, you need loopback for normal operation.  

To paraphrase something I said off-list: the domain I'm concerned
about is the same kind of hardened, tied-down system where Thor and I
had a strong gut reaction against devfs, due to security concerns.
Those same concerns apply here, mutatis mutandis.  Those concerns
include both actual functionality; concerns about the volume of code
you hvae to understand to get assurance; and the maturity of that
code.

When I build such systems, I've probably already stripped out gif,
tun, and probably ppp.  So, just personally, I don't care so much
about them.  But I can' strip out loopback. So.  Consider clonable
loopback in scenarios like the one I outlined in private email:
Configure two loopback interfaces, A and B. Configure one address on A
and another on B. Cons up a packet with A's source address and B's
destination address. If we were starting again de-novo, which
interface is semantically the ``right'' one to send that packet out?
Or for it to appear on?  If you're using filtering, which interfaces
should the filters name?  What about ICMP (currently tightly bound to
lo0)?

When I build hardeend systems, I really, really *dont want* to think
about all those hairy corner-cases issues. I'd much sooner wire down a
single loopback interface and be done with it, and not have to think
what games can be played by a bad-guy who gets root.

>And if you can ifconfig lo0 to your heart's content and set it to
>promiscuous mode, how will creating additional ones compromise security
>further? I can make a couple of tuns look effectively like loopback...

Again, I want to not *have* to think about a root compromise where
someone plays weird games with a clonable loopback. Speaking for
myself, I've already stripped out gre and tun and ppp (and strip and
/dev/fd), so none of those set off an alarm-bell for me.  Clonable
loobpack, OTOH, sets off a loud, un-ignorable alarm-bell vis-a-vis
hardened systems. At least for me.


>I would like to see a proposal on handling upper bounds on network
>device cloning as well as the justification for it. I.e. is there
>a separate sysctl per interface type? Does 0 mean as many as you want?

Re justification: if the above doesn't cut it, then I'll have to call
it quits.

Re more concrete proposals on bounds: I'd make 0 mean ``no more at
all'' and -1 mean all-you-can-eat.  That way we can map the same
values onto runtime sysctl knobs, should we wish to.

I agree a better, more fleshed-out proposal would be good. That can be
turned into documentation, and documentation is always good.



>| 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.
>
>There are many things that use cloning and need to be thought about
>individually. For example systrace, dmoverio, bpf, ptm, /dev/fd, etc.
>Again we should think about it and come up with a proposal.

That's good to hear. Right now, I'm still peturbed about loopback as a
special case.  I guess I can live with it for awhile, if we agree that
there will be suitable knobs soon.