[redhat-lspp] LSPP Development Telecon 10/16/2006 Minutes

[Paul Moore]

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.

James Morris wrote:
> On Tue, 17 Oct 2006, Venkat Yekkirala wrote:
> 
>>We are NOT overloading the security identifier (secmark) on the skb since
>>there's no such thing as an internal Vs. external label in the
>>secpoint design. There's only a "default" label that very intuitively
>>gets overridden by a "real" label that comes with the data
> 
> This approach is too confusing.  You will have to work within the 
> following constraints:
> 
> - Internal and external labeling mechanisms are entirely orthogonal: one 
> represents local knowledge of the packet and the other represents remote 
> information about a peer.
> 
> - Internal secmarks cannot be modified once set.
> 
> - Secmark will not be renamed.
> 
> - 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 suggest implementing a 'peer' class to manage IPsec labeling policy, 
> with a very simple policy construct similar to that of the packet class.
> 
> That way, the user can simply think about packets and peers when 
> configuring policy, which are representations of real things.

I'm glad to see there is still discussion going on over on the SELinux list
involving the secid patches but I'm a little concerned that there has not been
any real discussion about how to handle flow control while staying within the
constraints outlined above?  Venkat, is this something that has already been
taken into account and will appear in the next patch set?

I'm afraid that all we are doing is spending time and effort discussing a patch
set that has no chance of acceptance upstream and hence RHEL.

-- 
paul moore
linux security @ hp