On Mon, 2015-08-31 at 22:52 -0400, Paul Moore wrote:

On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez [off-list ref]
wrote:

quoted

On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:

quoted

On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
[off-list ref] wrote:

quoted

Even triggered updates make sense, since you can at least have
some form of trust
of where that binary policy came from.

It isn't always that simple, see my earlier comments about
customization and manipulation by the policy loading tools.

If the customization of the data is done in kernel then the kernel
can *first* verify the file's signature prior to doing any data
modification. If userspace does the modification then the signature
stuff won't work unless the tool will have access to the MOK and
can
sign it pre-flight to the kernel selinuxfs.

Yes, userspace does the modification.

quoted

quoted

quoted

Huh, not following? Perhaps, I am not following what your
laying down here.

 Right now there is no signing on the selinux policy file. We
should be able
to just use the firmware signing api's as is (I have not looked
on linux-next yet)
to unpack the blob.

I haven't looked at the existing fw signing hook in any detail to
be
able to comment on its use as a policy verification hook.  As
long as
we preserve backwards compatibility and don't introduce a new
mechanism/API for loading SELinux policy I doubt I would have any
objections.

You'd just have to implement a permissive model as we are with the
fw signing. No radical customizations, except one thing to note is
that on the fw signing side of things we're going to have the
signature
of the file *detached* in separate file. I think what you're
alluding
to is the issue of where that signature would be stuff in the
SELinux
policy file and its correct that you'd need to address that. You
could
just borrow the kernel's model and reader / sucker that strips out
the
signature. Another possibility would be two files but then I guess
you'd need a trigger to annotate both are in place.

Yes, there are lots of way we could solve the signed policy format
issue, I just don't have one in mind at this moment.  Also, to be
honest, there are enough limitations to signing SELinux policies that
this isn't very high on my personal SELinux priority list.

Hard for me to argue on your priorities.

I will point out for others interested, userspace does usually need to
munge policy. It's typically only needed when the policy on disk is say
v35, the toolchain understands v35+ but the kernel only understands
v34. The userspace tools will downgrade the policy before it loads
shoves in the blob.  If the kernel understands v35 and the policy is
v35 you can (I think) actually use cat to load the policy.

So certainly this is a perfectly reasonable restriction on some
systems, but we have quite often run into user who don't update their
kernel but do update their userspace and any signing would be pretty
much impossible for them...