From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6J5b4dY029327 for ; Sat, 19 Jul 2014 01:37:04 -0400 Received: by mail-pa0-f42.google.com with SMTP id lf10so6697777pab.1 for ; Fri, 18 Jul 2014 22:37:07 -0700 (PDT) Received: from [192.168.1.2] ([117.208.65.249]) by mx.google.com with ESMTPSA id dk1sm9902156pdb.20.2014.07.18.22.37.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 22:37:06 -0700 (PDT) Message-ID: <53CA03FF.9030507@gmail.com> Date: Sat, 19 Jul 2014 11:07:03 +0530 From: dE MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: Initial SIDs. References: <53C61881.1020304@gmail.com> <1405507280.12577.6.camel@x220.localdomain> In-Reply-To: <1405507280.12577.6.camel@x220.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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.