Re: Linux Firmware Signing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Roberts, William C wrote:
From: owner-linux-security-module@xxxxxxxxxxxxxxx [mailto:owner-linux-
security-module@xxxxxxxxxxxxxxx] On Behalf Of Joshua Brindle
Sent: Tuesday, September 1, 2015 7:13 AM
To: Paul Moore
Cc: Luis R. Rodriguez; Takashi Iwai; Ming Lei; David Howells; Peter Jones;
selinux@xxxxxxxxxxxxx; Schaufler, Casey; Stephen Smalley; Matthew Garrett;
Kees Cook; Vojtech Pavlík; Seth Forshee; james.l.morris@xxxxxxxxxx; Dmitry
Kasatkin; Johannes Berg; Joey Lee; Kyle McMartin; linux-
wireless@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Andy Lutomirski; linux-
security-module@xxxxxxxxxxxxxxx; Greg Kroah-Hartman; Vitaly Kuznetsov; David
Woodhouse
Subject: Re: Linux Firmware Signing

Paul Moore wrote:
<snip>
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 onmy personal SELinux priority list.

Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.


I'm not sure who "we" is as you are the only person I've heard advocating for removing that support.

The fact that there are so many userspace specific parts of the policy that never
make it into the kernel precludes any meaningful verification anyway.

Yes and no. On Android, if I was able to load a policy I could grant myself capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, not checking the
userspace portions Is not great. In an ideal world, everything is checked. However, the main
reason to doing it in the kernel is where you want your trust to be. For instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of verifying the policy signature
In the kernel, I need to trust only the kernel.

Especially on Android, userspace files are very important. Changing seapp_contexts or property_contexts can easily get you a privilege escalation to let you do whatever. Checking only the kernel binary is a half-solution and should not even be considered.


As far as the desktop environment, I claim ignorance and have no input there.

And SELinux already has a mechanism for raising the integrity of a process to do
things like signature checking in userspace, the domain transition. If someone
wants validation of the SELinux policy they just need to eliminate every domains
ability to load policy except for a trusted policy loader that does signature
checking.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at
http://vger.kernel.org/majordomo-info.html

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux