On Thu, Jun 25, 2020 at 9:25 AM Greg Kroah-Hartman
[off-list ref] wrote:

On Thu, Jun 25, 2020 at 08:56:10AM -0400, Stephen Smalley wrote:

quoted

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.

quoted

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.