* Initial SIDs.
@ 2014-07-16 6:15 dE
2014-07-16 10:41 ` Dominick Grift
0 siblings, 1 reply; 3+ messages in thread
From: dE @ 2014-07-16 6:15 UTC (permalink / raw)
To: selinux
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.
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Initial SIDs.
2014-07-16 6:15 Initial SIDs dE
@ 2014-07-16 10:41 ` Dominick Grift
2014-07-19 5:37 ` dE
0 siblings, 1 reply; 3+ messages in thread
From: Dominick Grift @ 2014-07-16 10:41 UTC (permalink / raw)
To: dE; +Cc: selinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Initial SIDs.
2014-07-16 10:41 ` Dominick Grift
@ 2014-07-19 5:37 ` dE
0 siblings, 0 replies; 3+ messages in thread
From: dE @ 2014-07-19 5:37 UTC (permalink / raw)
To: selinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-07-19 5:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-16 6:15 Initial SIDs dE
2014-07-16 10:41 ` Dominick Grift
2014-07-19 5:37 ` dE
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.