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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
