On Thu, Jun 25, 2020 at 10:26 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> 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. Looks like info->cmdline could be used as that key if set; we would just need a LSM hook to permit setting up the inode's security state based on that key. If that were passed to shmem_kernel_file_setup() as the name argument, then that might also help path-based LSMs although it seems potentially ambiguous.