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. > > On a different note, will the usermode blob be measured by IMA prior > > to execution? What ensures that the blob was actually embedded in the > > kernel image and wasn't just supplied as data through exploitation of > > a kernel vulnerability or malicious kernel module? > > No reason it couldn't be passed to IMA for measuring, if people want to > do that. Actually, I think it probably happens already via IMA's existing hooks but just wanted to confirm that IMA doesn't ignore S_PRIVATE inodes.
