Bill Sommerfeld writes: > On Tue, 2008-05-13 at 09:48 -0400, James Carlson wrote: > > Do zones have the NET_MAC_BYPASS privilege? Can they ever be > > granted it by the 'limitpriv' option in zonecfg? Or is this part of > > the "prohibited" set specified in /usr/lib/brand/native/config.xml? > > non-global zones clearly shouldn't get it by default. I'm not sure if > it should be added to the prohibited set -- I've added another question > for reviewers to my draft.
OK. I suspect that it should be prohibited, on the grounds that the MAC is necessary for proper operation of the zone separation in TX, and allowing that feature would allow unrestricted read- and write-up. It's also unclear to me whether the inbound demux would actually work right ... would the classifier be able to find the non-global zone socket to deliver the packet? > > and thus any unlabeled traffic > > should be discarded. (Yes, I realize that you're making IKE > > explicitly unlabeled, but I'm not real clear on the implications of > > that.) > > This doesn't follow; hosts may be label-aware, but, in real world > networks, the network between them may be label-hostile. I wasn't talking about the label-implied-by-something-else case. Other than for unlabeled nodes, which are not label-aware, the current code does _not_ support packets that lack labels. This option adds a new case: two label-aware hosts talking to each other using packets that lack labels. The only other case where we've had anything like that is with packets that cannot take a label (ARP) and where the communication is really kernel-to-kernel rather than user-to-user (NDP). > There are already a number of exceptions where we permit unlabeled > traffic to be received by label-aware hosts from other label-aware hosts > (see the OPT_NONE: case in tsol_get_pkt_label() in > uts/common/inet/ip/tnet.c). Yes. I wrote that code. ;-} Perhaps it doesn't matter, but in all of those cases, we're treating the data as not sensitive. It's admin_low, just like networking in the global zone itself. > > If there is a default label for a multi-level host, wouldn't that > > usually the _lowest_ level, not the highest, because you know > > nothing about the sender's intentions? > > Huh? We are considering sensitivity labels, not integrity labels. the > safest default is to assume highest sensitivity. since key management > runs in the global zone, it will be able to see the traffic. In that case, why not admin_high? I'm trying to figure out what the host's supported label range has to do with this, given that the packet itself has no label. Does this allow you to do something special, such as preventing some IKE speakers from talking with each other by setting incompatible labels? > > 5.5.2: > > > > This appears to reserve the names "inner" and "none" as names that > > cannot be used for symbolic labels. You might want to check with > > the TX folks to see if that can be done at all -- the namespace is > > supposed to be in the user's hands. (Perhaps you need a "label" > > keyword here so there's no ambiguity.) > > The spec states (pardon the LaTeXish): Ah, ok. It was the "in quotes" part that I'd missed. > > Are > > tunnels required for use with some deployments of TX+IPsec, or is > > this just an option? (Or does that "inner" keyword actually refer > > to the "internal" label described in section 2?) > > The latter. OK. Just because this is IPsec, I'm expecting to see tunnels show up somewhere. They always seem to. Thus my confusion on seeing "inner" here. I'd suggest using "internal" instead, or perhaps describing the label using the word "inner" in section 2. (But then you'll have fun with tunnels ... which will have an outer inner label and an inner inner one.) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
