On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <mcg...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
