Re: Initial SIDs.

[dE <de.techno@gmail.com>]

On 07/16/14 16:11, Dominick Grift wrote:
> On Wed, 2014-07-16 at 11:45 +0530, dE wrote:
>> I don't understanding why this's required.
>>
>> As per my understanding, the SID values can be generated by the kernel
>> given the security context and is internal to the kernel and independent
>> of the policy, so I don't understand why do we define SID manually.
>>
> I suppose it is about creating associations.
>
> In policy we associate customizable identifiers to hard initial sids
>
> I suppose to be able to do that we need to "declare" the hard isids in
> the first place (just like we are required to declare customizable
> identifiers)
>
> There are 4 reasons for isids:
>
> system initialization (to label processes that were there before any
> policy was loaded, think kernel threads)
>
> failover: selinux needs to be able to safely failover. Example you
> insert a device without labels. SElinux needs to kick in and make sure
> the device is labeled for consistency
>
> Another example: you load policy that removed some identifiers that are
> currently in use by the system. SELinux needs to kick in and mark those
> invalid
>
> There probably more reasons (i cant recall them at this very moment):
> they are briefly mentioned in the book "SELinux by example" ...
>
> .. a must read
>
>> Second, I'm not sure why these initial processes require an SID in the
>> 1st place – my guess is cause the security context of the parent
>> processes (like init) are used to compute the security context of it's
>> children; so with a missing security context of the parent process, it's
>> impossible to compute the security context of it's children. So a valid
>> security context has to be predefined.
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>

I bought that book and read up on it. Thanks for the reference.

These are reverse mapping of SIDs to labels, so they can be associated 
to any labels in case of situations like system initializations or 
undefined security labels etc... otherwise these undefined or missing 
labels cannot be resolved to an SID.