multiple secids on a sk_buff (Was: RE: [redhat-lspp] LSPP Development Telecon 10/16/2006 Minutes)

[Stephen Smalley]

On Thu, 2006-10-19 at 12:32 -0500, Venkat Yekkirala wrote:
> > NOTE: I've added Josh and Chris from Tresys to this thread as 
> > I don't believe
> > they are subscribed to the LSPP list and may not have seen this email.
> 
> I know Josh did, since he mentioned it in his email to me yesterday.
> 
> > > - No new field will be added to the skb.  If you need to 
> > encode multiple 
> > > things on secmark, do it internally (as I've suggested a 
> > couple of times).
> 
> I am not sure encoding multiple secids on the secmark is feasible
> or desirable. I will have to rely on Stephen and others to weigh in
> here.

What are the perceived benefits (vs. secid reconciliation)?
- retain separation between "internal" and "external" labeling.
- retain immutable nature of "internal" secmarks.

What doesn't change?
- checking between "internal" and "external" labels is still required to
enforce certain kinds of constraints (correct?).

What are the perceived costs (vs. secid reconciliation)?
- halving of the SID space.
- duplication of interfaces to get the desired information (SO_PEERSEC,
SCM_SECURITY x 2, once for "external", once for "internal"), unless we
define a fallback behavior within the existing interface (i.e.
effectively reconcile them at the end).
- duplication of per-packet send/recv checks (packet send/recv based on
"internal" label, labeled-networking-mechanism-specific check based on
"external" label) and dependence on choice of labeling mechanism in
policy.

Is that accurate?

> There's another potentially bad way to handle this which is to leverage
> the sp field on the skb. I don't know how James feels about it. James?

Could you spell that out a bit?  Same as above, except for halving the
SID space and possible issues with sharing and lifecycle of sec_paths?

-- 
Stephen Smalley
National Security Agency