lkml.org 
[lkml]   [2015]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux Firmware Signing
From
On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <mcgrof@suse.com> 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


\
 
 \ /
  Last update: 2015-08-28 02:21    [W:0.431 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site