On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:

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

quoted

On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
Right so now that firmware usermode helper is behind us (systemd ripped it) we
do the fs lookup directly ourselves. One of my side goals with the extensible

Totally agreed: nothing uses the usermode helper any more, so we
should ignore that moving forward.

Great the patches I have in place for the system data helpers let us
deprecate this and put that code in a dark corner.

quoted

We have no LSM hook for kexec, even though the kernel does have access to the
fd, so if you wanted the struct file for an LSM it should be possible as the
syscall for kexec is:

I can send a patch to add this; it should be trivial. :) (It's not
high on my TODO list at the moment just because Chrome OS doesn't use
kexec.)

If there are no users for it and since we are talking about bringing
things together I'd prefer if we try to come up with a shared solution
for that as it seems it can wait for kexec.

quoted

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.

Those syscalls were needed because the original ones were designed a
long time ago. :)

OK fine :)

quoted

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.

  * modules
  * firmware / system data

modules + firmware: there seems to be some code sharing we could possibly do
for both fw_read_file() and copy_module_from_fd(), note we are going to use
different keys for vetting each of these. It may be possible to share the
LSM hook here. All parties would just need to agree.

As long as the LSM know what kind of file it's loading, and has access
to the fd (and for IMA, the blob loaded from that fd), that should be
everything it needs. IMA has the name and blob, loadpin has the fd,
and a future signature-checking LSM could be able to look up signature
type from the load type, and split the key off (or fetch the key file)
itself.

OK great, I think that instead of passing the actual routine name we should
instead pass an enum type for to the LSM, that'd be easier to parse and we'd
then have each case well documented. Each LSM then could add its own
documetnation for this and can switch on it. If we went with a name we'd have
to to use something like __func__ and then parse that, its not clear if we need
to get that specific.

If we expect to stack signature checkers, we can optimize the
signature parsing/loading infrastructure then. But since we have
neither the sigchecking LSM nor multiple ones, we can leave that to
later.

Sure.

  Luis