On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez [off-list ref] wrote:

On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:

SELinux uses: security_load_policy(data, len), refer to selinuxfs sel_load_ops.
Since its write operation on its file_operation is sel_write_load() and that
is as follows:

static ssize_t sel_write_load(struct file *file, const char __user *buf,
                              size_t count, loff_t *ppos)
{
        ...
}

We should be able to add yet-another LSM hook here to let the kernel / LSM have
access to the inode, is that LSM hook desirable ? But folks, before you answer
note that there's a growing trend here! Its point 1 Kees had made earlier.  I
was hesitant to go into details as I think fw signing needs to be baked first
but.. since we're reviewing all these details now it seems logical to go down
the rabbit hole further.

Everywhere where we fetch a file from within the kernel either directly (say
firmware load, 802.11 regulatory request) or from userspace request (SELinux
policy load node) we end up having to sprinkle a new LSM hook. In fact for
modules and kexec there were syscalls added too. There might be a possiblity
for sharing some of these requests / code so some review is in order for it.

Here's my review if we wanted to try sharing things, in consideration and
review of:

  * SELinux policy files
  * modules
  * firmware / system data (consider replacing CRDA)
  * kexec

----

  * SELinux policy files:

sel_write_load() is very specific, its part of the selinuxfs and it just
uses copy_from_user() to dump the data from the file onto a vmalloc'd
piece of memory. We don't exactly read arbitrary files from the fs then.
If we *really* wanted to generalize things further we probably could
but I'm not going to lead any discussion about design over selinuxfs,
I'll let the folks behind it think about that themselves.

While I question the usefulness of a SELinux policy signature in the
general case, there are some situations where it might make sense,
e.g. embedded systems with no post-build customizations, and I'm not
opposed to added a signature to the policy file for that reason.
However, I haven't given any serious thought yet to how we would
structure the new blob format so as to support both signed/unsigned
policies as well as existing policies which predate any PKCS #7
changes.

-- 
paul moore
www.paul-moore.com