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?
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...

| 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?

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?

| 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.

christos