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

[James Morris]

On Thu, 19 Oct 2006, Stephen Smalley wrote:

> What are the perceived costs (vs. secid reconciliation)?
> - halving of the SID space.

In a binary fashion :-)  So it's 2^(32/2)  and I'd imagine we need to use 
one bit to indicate that label partitioning was active.

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

I wouldn't expect these APIs to return anything for internal labels.

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

Yep.

The big advantage, though, is simplicity.  This is something I can explain 
to anyone technical.

a) "use iptables to classify and label a packet"

b) "use ipsec to tell you who you're talking to at the other end"


secid reconciliation is confusing even for core SELinux developers, and we 
fairly obviously can't proceed in that direction.


-- 
James Morris
<jmorris at namei.org>