On Thu, Jun 25, 2020 at 11:21 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2020/06/25 23:26, Stephen Smalley wrote: > > On Thu, Jun 25, 2020 at 9:25 AM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On Thu, Jun 25, 2020 at 08:56:10AM -0400, Stephen Smalley wrote: > >>> No, because we cannot label the inode based on the program's purpose > >>> and therefore cannot configure an automatic transition to a suitable > >>> security context for the process, unlike call_usermodehelper(). > >> > >> Why, what prevents this? Can you not just do that based on the "blob > >> address" or signature of it or something like that? Right now you all > >> do this based on inode of a random file on a disk, what's the difference > >> between a random blob in memory? > > > > Given some kind of key to identify the blob and look up a suitable > > context in policy, I think it would work. We just don't have that > > with the current interface. With /bin/kmod and the like, we have a > > security xattr assigned to the file when it was created that we can > > use as the basis for determining the process security context. > > My understanding is that fork_usermode_blob() is intended to be able to run > without filesystems so that usermode blobs can start even before global init > program (pid=1) starts. > > But SELinux's policy is likely stored inside filesystems which would be > accessible only after global init program (pid=1) started. > > Therefore, I wonder whether SELinux can look up a suitable context in policy > even if "some kind of key to identify the blob" is provided. > Also, since (at least some of) usermode blob processes started via > fork_usermode_blob() will remain after SELinux loads policy from filesystems, > I guess that we will need a method for moving already running usermode blob > processes to appropriate security contexts. > > Is my understanding/concerns correct? It isn't fundamentally different than the issue of program execution from a filesystem prior to initial policy load, e.g. executing programs from the initrd or executing init from the "real" root. Absent a policy, the process will just remain in the initial SID/context (kernel SID), which will later be mapped to a context when policy is loaded. Typical init programs address this by either re-exec'ing themselves after policy load or by dynamically switching contexts via write to /proc/self/attr/current. The kernel doesn't try to retroactively transition previously started processes; they are expected to either exit prior to policy load (ala transient processes run from initrd) or re-exec or set their contexts after policy load.
