Bill Sommerfeld wrote:
> A revised design document incorporating responses to the comments so
> far, plus a glossary of terms used in the document, is now available at:
>
> http://www.opensolaris.org/os/project/txipsec/Design/phase1-0.4.pdf
>
> If you did not reviewed the previous version, please review the new
> version instead; the glossary should make it more approachable.
>
> If you have commented on the previous version, please review this
> version to ensure it adequately reflects your comments.
>
5.2- SADB: unlabeled SAs.
I think the behavior for backward compatible unlabeled SAs is
already determined. The system needs to apply the existing orthogonal
MAC policy to determine whether to apply a CIPSO label. One difficulty
is that is the decision to add CIPSO is made based on the destination
then integrity should be calculated with the option present while if the
decision is made to add CIPSO for an unlabeled destination due to the
gateway then integrity should be calculated before CIPSO is applied. I
think the ability to handle gateway induced CIPSO is something you want
to put off until the next phase.
5.3 TN packet processing
I'm not thrilled with this solution since I think it is necessary to
be able to do implicit labeling where sections of the network are aware
that the end points are labeled and have differing policies about the
max label of the endpoints non-IPsec traffic.
I also think that the primary reason why this would need to be a
different privilege and socket option from mac exempt is that it
reintroduces a more problematic approach to MAC exceptions where the
gateways/destinations have to be complicit in the exception rather than
the privileged party performing the transform to the gateway/destination
label.
I can take a stab at how it would work and not affect the TN DBs or
how we search them. But it does require elements of cred reform. In
phase 1, I think we can work with some restrictions so not all of this
should be necessary, but I don't want it to force us back into
problematic MAC policies.
---------------------- Example Model ---------
Current semantics for next hop:
A gateway is labeled and affect labeling decisions or a gateway is
unlabeled and does not affect labeling decisions. A route irregardless
of secattrs has the affect of its gateway.
Addition for next hop:
A secattr can be single labeled and marked unlabeled/hostile.
Packets implicit label must exactly match (or we wouldn't have selected
it.) Packets must be TSLF_UNLABELED to pass or TSLF_IMPLICIT to be
stripped of CIPSO labels.
Current (theoretical) semantics for MAC_EXEMPT:
For packets to unlabeled peers the label is transformed to the label
of the peer which must be dominated by the privileged process' label.
Route selection and consequent gateway label addition is based on the
new label.
Addition for MAC_EXEMPT', (CIPSO peer) MAC_EXEMPT :
The packet cred label is TSLF_IMPLICIT and transformed to the peers max
endpoint label, which must be dominated by the privileged process'
label. This is the def_label for ULS and max_label for MLSes. (Though
should we really be ignoring non dominated sl_set labels?) (From cred
reform the cred label is TSLF_UNLABELED if the destination was unlabeled.)
Current gateway/destination:
An unlabeled packet from a CIPSO host is dropped.
Theoretical gateway/destination: (CR# 6517744 is open for the unlabeled
destination case)
An unlabeled packet from a CIPSO host is dropped unless: while assuming
a shared TNDB with the source, its intended label can be exactly
established and is consistent for the sender (within range or slset.)
Addition:
An unspecified label packet from an MLS host in addition to the current
TSLF_UNLABELED flag will be given an TSLF_IMPLICIT flag. Only those
with MAC_EXEMPT` able to receive at the deduced label will receive it
locally and no labeling will be added in forwarding.
Expected Result:
The route secattr is a bit more flexible since we can properly tag
the routes that unprotected CIPSO should not take.
Two CIPSO hosts must have the same max_label for symmetric
communication without labels.
I think MAC_EXEMPT' could have the same privilege as MAC_EXEMPT
since it is no worse then sending to a unlabeled host with a
default_label, but it would require a specific differentiator when
setting the option for those expecting it to influence only unlabeled
host communications.
-----------------------------
Primary requirements on phase 1 from the example model:
Two CIPSO hosts must have the same max_label for communication
without labels.
TSLF_IMPLICIT is marked on incoming packets in tsol_get_pkt_label
and taints them for forwarding and local delivery besides iked with its
new privilege protected socket option. (Assuming labeled gateways can
be unfriendly to implicit labels in phase 1.)
-Will
> - Bill
>
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>
