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.

>   "Inbound traffic from multi-label hosts not bearing an explicit
>   sensitivity label will be assigned the highest sensitivity label
>   allowed for the host in the tn*db and processed accordingly."
> 
>   Is that compatible with what we do today?  

Yes.

> I thought that all multi-level hosts were label-aware, 

Correct.

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

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

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

>   If you choose the highest
>   sensitivity allowed, then what compartments do you choose?

The clearance for a host includes the compartments it is allowed to see;
we'll use the upper bound of the label range assigned to the host.

> 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):
        
        In the foregoing, {\em label} may be either a binary label in
        hexadecimal form (such as {\tt 0x0002-08-08}) or a string-form
        label in quotes (such as {\tt "PUBLIC"} or {\tt "SANDBOX
        PLAYGROUND"})
        
There is thus no ambiguity.

If your local DOI has an "inner" label, you'd specify its use as an
outer label via:

        wire-label "inner"

vs

        wire-label inner


>   "wire-label inner" seems to assume that a tunnel is in use. 

This is not correct; a packet can have distinct inner and outer
sensitivity even if there isn't an inner ip header -- the inner
sensitivity is a property of the security association and doesn't occupy
any space in the packet.

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

>   The broader question: is there anything 'special' about how tunnels
>   would be expected to be used with TX?

I don't believe so but some testing of this lies in my future..



Reply via email to