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