[redhat-lspp] Creating a context/SID for MLS CIPSO packets

[Paul Moore]

Stephen Smalley wrote:
> On Thu, 2006-03-16 at 13:26 -0500, Paul Moore wrote:
> 
>>Traditional CIPSO only sends the MLS label along with the packet.  This 
>>is fine for traditional MLS systems but causes problems here in TE land. 
>>  The problem being, how does one create a full SELinux context/SID with 
>>only the MLS label?
>>
>> From my limited knowledge of the security server, it looks like the 
>>best way is to create a new entry in the policy's default context field, 
>>policydb->ocontexts[OCON_NETLBL], with a default context minus the MLS 
>>label.  Whenever a MLS CIPSO packet arrives I could generate a context 
>>using the default context and the MLS label and do a sidtab_search(). 
>>If the results did not yield an existing SID I would insert the new 
>>context into the SID table.
>>
>>So SELinux gurus I ask you, is that a reasonable approach?  Or am I 
>>missing something here and way off base?
> 
> That requires an extension to the policy format to store that entry,
> with corresponding changes to both the kernel and libsepol/checkpolicy.
> Not something to do if you can avoid it.

Yes, I wasn't looking forward to that ...

> Better if you can just leverage one of the existing initial SID's and
> use its context as the baseline, modified by the received MLS label.
> This is the approach used for dealing with an on-disk file xattr that
> lacks a MLS field for compatibility; if the context lacks the MLS field,
> then the MLS level is pulled from the default file SID for the
> superblock, which is SECINITSID_FILE unless otherwise specified by the
> defcontext= mount option.  In your case, you would do something similar
> but inherit everything but the MLS field from some initial SID.  The
> initial SIDs are mapped to contexts by initial_sid_contexts.  Note that
> they are only processed upon initial policy load, not reloads.  So if
> you can leverage one of the already defined ones (e.g. netmsg aka
> SECINITSID_NETMSG) that has become unused, then that would be optimal.

Okay, I'll look into reusing the netmsg context.

Thanks.

-- 
paul moore
linux security @ hp