On Wed, 2006-12-13 at 10:27 -0600, Joe Nall wrote: > On Dec 13, 2006, at 9:35 AM, Stephen Smalley wrote: > > > On Wed, 2006-12-13 at 09:23 -0600, Joy Latten wrote: > >> On Tue, 2006-12-12 at 10:41 -0500, Paul Moore wrote: > >> > >>> > >>> Hmmm, if I am following this correctly we are going to need to > >>> manually setup a > >>> SA for every context we want to send over loopback because racoon > >>> can't > >>> negotiate with itself? If that's the case I think we really need > >>> to get racoon > >>> working for loopback because I don't believe the current solution > >>> is very > >>> practical ... > >>> > >> I am not fully understanding something... what will labeled ipsec > >> over > >> loopback be used for? > >> > >> Someone asked on ipsec-tools list and I could not come up with an > >> explanation. > > > > To provide the peer label information on loopback connections or > > datagrams. Same as using NetLabel on loopback. > > Exactly. getpeercon should work consistently over > lo > ethX when two processes on the same machine communicate > ethX when two processes on different machines communicate > > The first two should require no configuration. The latter requires > NetLabel, secmark or labeled IPSec and coordinated policy. LSPP.51 > was almost there and is what we are still using internally for > applications development.
lspp.51 included the secid reconciliation patches that (for better or worse) were not accepted. So continuing to do applications development on that kernel isn't advisable IMHO - it won't match what will be in RHEL 5 (which I believe requires configuration of NetLabel or xfrm labeling for even local communications if you want peer labeling) or even in later upstream kernels (if Venkat is successful with his new approach) since secmark is now kept separate. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
