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?
