On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
> Luis R. Rodriguez <[email protected]> wrote:
>
> > But note, we also have kexec_file_load() syscall and an arch specific
> > signature verification feature, arch_kexec_kernel_verify_sig().
> > Sad trombone, no LSM hook and only x86 supports this :(
>
> It's arch-specific because kexec on x86 has to deal with UEFI, PE and
> Microsoft standards. As far as I'm aware, there is no kernel image signing on
> other arches - though rumours abound that this may not remain so. However,
> also as far as I'm aware, only the PE file format defines an in-built signing
> method; ELF does not.
Should it? :) Thanks for the details BTW !
> > > > >> 2) instead of having signature checking happening in distinct places
> > > > >> in kernel module execution path and firmware execution paths, move all
> > > > >> signature checking into a separate minor LSM, which can stack with
> > > > >> whatever other LSM is running. For example, if SELinux wanted to do
> > > > >> its own signature checking, it could.
> >
> > To clarify -- this idea sems from the fact that we can now stack
> > LSMs. That's a *brand spanking new* feature and that opens the door for new
> > optimizations that we could not have done before!
>
> The LSM stack is just an interface by which things like module loading could
> access things that do signatures rather than doing them directly.
>
> The tricky bit is working out where to make the split. Take module loading as
> an example. We start off with one blob that is the ELF module plus a
> signature. Should the module loader split off the signature or should it
> leave that to the LSM? If the latter, do we need to iterate through all
> interested LSMs repeatedly, allowing them to strip their recognised
> signatures, until none of them show further interest? How do we handle the
> possibility of at some time in the future being given two separate pieces by a
> new interface?
Agreed! Its why I noted, this is super long term. Even though it is IMHO
thinking in the right path forward, its quite a bit of steps ahead of where we
are and we first need to bake firmware / system data / SE Linux policy file
signing before we even start looking at further code sharing or optimizations.
Without proper context some folks might think this needs to happen right away,
*it can't*, we need to do quite a bit more work first.
> > One patch not merged upstream or in linux-next is:
> >
> > "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> >
> > https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=f5e057ee8ab3596dc39f582882104fa5d6ea9250
> >
> > This extends sign-file support to insert a PKCS#7 authenticated attribute from
> > where it can be extracted by the kernel. We need to consider if we still need
> > this, I believe Andy suggested this. We may need a similar name attribute for
> > SELinux policy files, we may then also need to extend sign-file support for
> > SELinux policy files as well. Unless of course, SELinux wants to start loading
> > policy files from a /lib/firmware path, but I doubt this. Anyway this name
> > policy requirement is something we need to discuss _now_ for both firmware /
> > system data and I guess now SELinux policy files.
>
> Indeed. One thing I have done in my patches is to introduce categorisation of
> what a key is permitted to do and what a signed object is. I've then
> implemented a policy that controls what keys may be used to verify which
> objects.
>
> For example, if a key has CA information, it is only allowed to verify other
> keys and isn't permitted to verify modules, firmware, etc..
>
> However, what categories should be available? So far, I have:
>
> enum key_being_used_for {
> VERIFYING_MODULE_SIGNATURE,
> VERIFYING_FIRMWARE_SIGNATURE,
> VERIFYING_KEXEC_PE_SIGNATURE,
> VERIFYING_KEY_SIGNATURE,
> VERIFYING_KEY_SELF_SIGNATURE,
> VERIFYING_UNSPECIFIED_SIGNATURE,
> };
>
> However, given what Luis is talking about, the 'firmware' category might need
> splitting up - but into what pieces?
Right so this stems from two things:
1) Since we're going to re-use firmware APIs for system data files, we want to
extend support for other users but also enable them to replace their own
userspace application, my own goal is to replace CRDA for regulatory.bin
fetching. One use case then is to enable Kconfig options for these users to let
them have distro options to require or not signing of their own system data
files. Since CRDA was optional, so would requiring signature on the target
file, and this should be available even if a distribution did not require
firmware signing.
2) I'm told some drivers may want the ability to have their own Kconfig option
and *really* want firmware signing capabilities ASAP, with their public key
embedded as part of the build, letting some distros ignore it, but obviously
with a desire to enable some others to enable this option right away and
recommend it.
My original approach to firmware signing [0] was to have *one* kconfig option to
let distros either opt-in all firmware signing or disable it. That raised the
question of who would sign all those /lib/firmware files and the obvious choice
was to hope Kyle would as he maintains linux-firmware. Kyle expressed he's
willing to do us that favor but because of 2) it would seem we also want to
have the option to let driver developers customize their crytpo requirements,
that includes the key. That would mean adding more arguments to the request,
and if we want to do that that's best done through the newer API which lets us
tuck that in through a descriptor, rather than extending the series of
arguments we have already and affecting all callers in kernel for the existing
firmware API. So contrary to my original approach [0] of adding system data
APIs later which enables an extensible firmware API *later* and then allowing
customizing crypto preferences / requirements only for 802.11 it seems we
may want that from the start for drivers. This is why I'm now working on
first adding the extensible firmware API, the system data stuff, first,
without any crypto stuff. And later slowly add in the signing stuff.
Since people really interested in firmware signing come from camp 2) above it
would seem we want to *encourage* suppliers of firmware to sign firmware for us
so we know its coming from them, and only as a last resort should we rely on
Kyle's key (no offense Kyle). In fact in retrospect a key with such broad
ability to sign a lot of firmware for the kernel seems like a bad idea now. As
I envision this now then, based on these observations, then each driver would
then just fill in the descriptor with their custom signing requirements. We
want to be explicit about this criteria and want folks who get / upload
firmware to *really* think about this. We can still default to Kyle's key but I
think that should be also an explicit action.
Since keys become very specific then we wouldn't want Intel signing Broadcom's
keys for instance, hell we probably would not want Intel's wireless team with
power to sign Intel's Ethernet driver firmware as well, for instance. Likewise
for 802.11 regulatory data we do not want that key to sign any other data for
the kernel. Keep this in mind for now, I'll elaborate on that later.
[0] http://lkml.kernel.org/r/[email protected]
Now let's review the SELinux stuff before we jump back into firmware / system
data stuff again as there is a joint criteria to consider for all of these.
For other people's refrence the enum you quote above was added through your
patch pending on linux-next:
"PKCS#7: Appropriately restrict authenticated attributes and content type"
Based on what Roberts seems to want to do for SELinux policy files it would
seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
to kick off security_load_policy(data, count), so its not exactly a
yet-another-API to read arbitrary files from the file system. Its policy files
are also very distribution specific. Because of all this its not really
suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
candidate already to make use of the system_verify_data() APIs you added David,
provided the items below are taken care of as well.
Other than the enum usage David has a pending patch which is not on linux-next
which interested folks in using system_verify_data() should look at:
"X.509: Restrict the usage of a key based on information in X.509 certificate"
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e7302137
This extends the OID registry with:
1.3.6.1.4.1.2312.16 Kernel OIDs
1.3.6.1.4.1.2312.16.1 - X.509 extendedKeyUsage restriction set
1.3.6.1.4.1.2312.16.1.1 - Firmware signing only
1.3.6.1.4.1.2312.16.1.2 - Module signing only
1.3.6.1.4.1.2312.16.1.3 - Kexecable image signing only
I think we'll need now also these:
1.3.6.1.4.1.2312.16.1.4 - 802.11 regulatory data
1.3.6.1.4.1.2312.16.1.5 - SELinux policy signing only
The state of affairs in terms of people intersted in firmware signing wanting
to be more specific about their key usage (item 2 above) seems to imply that we
may want to think carefully before assuming a general board firmware key
should be used (let's say Kyle's) and trusted. That would limit the use of a
broad OID 1.3.6.1.4.1.2312.16.1.1. In fact since the desire of interested folks
seem to be to want to make the keys very specific perhaps we should consider a
way to grow the OID registry dynamically at run time. We don't have support for
that yet.
Users of that then would be:
* SELinux policy folks
* 802.11 regulatory
* Driver vendors who want to customize their firmware signing specification
Would doing this be OK? That would enable the OID registry to grow dynamically
by the driver having to place their requirements only in their driver, instead
of having to extend the registry manually on a specific kernel.
> [Note that the above also allows for non-verification usages. Keys can be
> marked with what they're allowed to do out of signing, verifying, encrypting
> and decrypting and this can be qualified further.]
Thanks that's useful information.
> Also, do I actually need to label signatures with the name that will be passed
> to request_firmware()? Or is it better to do it just by requiring each driver
> that wants a piece of firmware to hold a key or a reference to a key or a hash
> for the particular piece of firmware that it wants? Having a name in the
> signature at least makes for more readable error messages, but...
I'll chime in, but I'd like other people's feeback as well, in
particular Andy and Roberts. As it stands, you had this patch which was
not yet posted, in it you have a named attributes for firmware:
"PKCS#7: Add an optional authenticated attribute to hold firmware name"
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
1.3.6.1.4.1.2312.16 Linux kernel
1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
1.3.6.1.4.1.2312.16.2.1 - firmwareName
I take it you are referring to this? If we follow this model we'd then need
something like:
1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
That should mean each OID that has different file names would need to be
explicit about and have a similar entry on the registry. I find that pretty
redundant and would like to avoid that if possible.
If the driver specifies the trusted key through its desciptor, as you suggest,
I do agree we could do away with this. The change here would be that each
driver that wants firmware signing should opt-in carefully with the key that it
does trust. Most active vendors would swiftly want to only trust their own key.
With this model then we would have these options:
* SYSTEM_DATA_SIG enabled
Enables system data signing, drivers need to be explicit about wanting
this as well. By default Kyle's key is trusted if the API is used, this
does require an explicit change to the new API though. Support for signing
is available but by default its permissive. A kernel parameter exists so
that upon bootup its in enforced mode. Drivers can still override
this and *require* the signature always, but if they want that they need to be
explicit about it on their driver call. They can do this through their own
Kconfig option or just always have it, up to them.
* SYSTEM_DATA_SIG_FORCE enabled
Requires all uses of the API to have a trusted key before passing data back.
* No Kconfig option for SYSTEM_DATA_SIG set
Uses of desc->signature_required will fail to compile, folks will need to
wrap this descriptor's setting with either SYSTEM_DATA_SIG or their own
Kconfig option which selects SYSTEM_DATA_SIG.
SELinux could copy this model, they could end up with for instance:
* SECURITY_SELINUX_POLICY_SIGNED enabled
Enables signature on the policy file. A kernel parameter could kick the
signature to be required.
* SECURITY_SELINUX_POLICY_SIGNED_FORCE enabled
The policy files require a signature.
Does this seem fine? If so then ideally we'd want the dynamic OID registry but
I don't think that's a requirement, for now we could add users as time goes by.
Other than that, I think we'd need to define the allowed crypto options that can
be passed to system_verify_data() ? Uptimately this is also what we want to
enable drivers to fill in through a static descriptor.
Luis
On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
> Now let's review the SELinux stuff before we jump back into firmware / system
> data stuff again as there is a joint criteria to consider for all of these.
> For other people's refrence the enum you quote above was added through your
> patch pending on linux-next:
>
> "PKCS#7: Appropriately restrict authenticated attributes and content type"
>
> Based on what Roberts seems to want to do for SELinux policy files it would
> seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
> unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
> to kick off security_load_policy(data, count), so its not exactly a
> yet-another-API to read arbitrary files from the file system. Its policy files
> are also very distribution specific. Because of all this its not really
> suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
> candidate already to make use of the system_verify_data() APIs you added David,
> provided the items below are taken care of as well.
One thing to keep in mind is that not only are SELinux policy files
distribution specific, they are machine specific as administrators
can, and do, customize the policy for their usage. I really like the
idea of providing signed SELinux policies to the kernel but I question
how practical it will be for normal users/admins.
Some of the Machine Owner Key (MOK) work would likely be necessary for
signed SELinux policies to be even remotely practical.
>> Also, do I actually need to label signatures with the name that will be passed
>> to request_firmware()? Or is it better to do it just by requiring each driver
>> that wants a piece of firmware to hold a key or a reference to a key or a hash
>> for the particular piece of firmware that it wants? Having a name in the
>> signature at least makes for more readable error messages, but...
>
> I'll chime in, but I'd like other people's feeback as well, in
> particular Andy and Roberts. As it stands, you had this patch which was
> not yet posted, in it you have a named attributes for firmware:
>
> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
>
> 1.3.6.1.4.1.2312.16 Linux kernel
> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
>
> I take it you are referring to this? If we follow this model we'd then need
> something like:
>
> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
Assuming I'm understanding the firmwareName attribute idea correctly,
we don't need to worry about that from a SELinux policy point of view.
As others have already stated, the kernel just reads a binary blob
that is pushed into it by userspace using securityfs.
> If the driver specifies the trusted key through its desciptor, as you suggest,
> I do agree we could do away with this. The change here would be that each
> driver that wants firmware signing should opt-in carefully with the key that it
> does trust. Most active vendors would swiftly want to only trust their own key.
See my earlier comments about SELinux policy customization.
> With this model then we would have these options:
>
> * SYSTEM_DATA_SIG enabled
>
> Enables system data signing, drivers need to be explicit about wanting
> this as well. By default Kyle's key is trusted if the API is used, this
> does require an explicit change to the new API though. Support for signing
> is available but by default its permissive. A kernel parameter exists so
> that upon bootup its in enforced mode. Drivers can still override
> this and *require* the signature always, but if they want that they need to be
> explicit about it on their driver call. They can do this through their own
> Kconfig option or just always have it, up to them.
>
> * SYSTEM_DATA_SIG_FORCE enabled
>
> Requires all uses of the API to have a trusted key before passing data back.
>
> * No Kconfig option for SYSTEM_DATA_SIG set
>
> Uses of desc->signature_required will fail to compile, folks will need to
> wrap this descriptor's setting with either SYSTEM_DATA_SIG or their own
> Kconfig option which selects SYSTEM_DATA_SIG.
>
> SELinux could copy this model, they could end up with for instance:
>
> * SECURITY_SELINUX_POLICY_SIGNED enabled
>
> Enables signature on the policy file. A kernel parameter could kick the
> signature to be required.
>
> * SECURITY_SELINUX_POLICY_SIGNED_FORCE enabled
>
> The policy files require a signature.
>
> Does this seem fine? If so then ideally we'd want the dynamic OID registry but
> I don't think that's a requirement, for now we could add users as time goes by.
> Other than that, I think we'd need to define the allowed crypto options that can
> be passed to system_verify_data() ? Uptimately this is also what we want to
> enable drivers to fill in through a static descriptor.
>
> Luis
--
paul moore
http://www.paul-moore.com
Luis R. Rodriguez <[email protected]> wrote:
> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
>
> 1.3.6.1.4.1.2312.16 Linux kernel
> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
>
> I take it you are referring to this?
Yes.
> If we follow this model we'd then need something like:
>
> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
>
> That should mean each OID that has different file names would need to be
> explicit about and have a similar entry on the registry. I find that pretty
> redundant and would like to avoid that if possible.
firmwareName is easy for people to understand - it's the name the kernel asks
for and the filename of the blob. seLinuxPolicyName is, I think, a lot more
tricky since a lot of people don't use SELinux, and most that do don't
understand it (most people that use it aren't even really aware of it).
If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
so - even if you dress it up as a path (/lib/firmware/<firmwareName>).
David
See http://www.infradead.org/rpr.html
> Luis R. Rodriguez <[email protected]> wrote:
>
>> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
>> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
>>
>> 1.3.6.1.4.1.2312.16 Linux kernel
>> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
>> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
>>
>> I take it you are referring to this?
>
> Yes.
>
>> If we follow this model we'd then need something like:
>>
>> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
>>
>> That should mean each OID that has different file names would need to be
>> explicit about and have a similar entry on the registry. I find that
>> pretty
>> redundant and would like to avoid that if possible.
>
> firmwareName is easy for people to understand - it's the name the kernel
> asks
> for and the filename of the blob. seLinuxPolicyName is, I think, a lot
> more
> tricky since a lot of people don't use SELinux, and most that do don't
> understand it (most people that use it aren't even really aware of it).
>
> If you can use the firmwareName as the SELinux/LSM key, I would suggest
> doing
> so - even if you dress it up as a path (/lib/firmware/<firmwareName>).
>
> David
>
In conversation with Mimi last week she was very keen on the model where
we load modules & firmware in such a fashion that the kernel has access to
the original inode -- by passing in a f2f, or in the firmware case by
doing the rd lookup directly. So surely you have all the SELinux labelling
you need?
--
dwmw2
On Wed, Aug 26, 2015 at 10:35:19PM -0400, Paul Moore wrote:
> On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez <[email protected]> wrote:
> > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
> > Now let's review the SELinux stuff before we jump back into firmware / system
> > data stuff again as there is a joint criteria to consider for all of these.
> > For other people's refrence the enum you quote above was added through your
> > patch pending on linux-next:
> >
> > "PKCS#7: Appropriately restrict authenticated attributes and content type"
> >
> > Based on what Roberts seems to want to do for SELinux policy files it would
> > seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
> > unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
> > to kick off security_load_policy(data, count), so its not exactly a
> > yet-another-API to read arbitrary files from the file system. Its policy files
> > are also very distribution specific. Because of all this its not really
> > suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
> > candidate already to make use of the system_verify_data() APIs you added David,
> > provided the items below are taken care of as well.
>
> One thing to keep in mind is that not only are SELinux policy files
> distribution specific, they are machine specific as administrators
> can, and do, customize the policy for their usage. I really like the
> idea of providing signed SELinux policies to the kernel but I question
> how practical it will be for normal users/admins.
Yeah that makes it harder. Possible but harder.
> Some of the Machine Owner Key (MOK) work would likely be necessary for
> signed SELinux policies to be even remotely practical.
Matthew, Peter and Gary are Cc'd, so they can feel free to chime in.
There are other alternatives as well:
* Is there wide use of SELinux + IMA ? If so that may be another option.
* The kernel cert stuff can also allow for installing keys *later* which
could be trusted specifically for SELinux Policy files, but that'd
mean having to generate / sign these someway up in the food chain.
These are all worth considering not just for SELinux but any other form of
machine-specific data from files which might need to be fed to the kernel.
Are there other use cases other than SELinux policy files?
Anyway, its good we're reviewing this early before patches for SELinux
policy file stuff for signing are brewed. The APIs will be there, but need
to be advanced slightly for firmware signing anyway so there is time for
you folks to think about what route you want to go. If you *do* determine
you need it, it seems pretty easy to handle.
> Assuming I'm understanding the firmwareName attribute idea correctly,
> we don't need to worry about that from a SELinux policy point of view.
> As others have already stated, the kernel just reads a binary blob
> that is pushed into it by userspace using securityfs.
Ah thanks, great, one less thing to think about. So it would just be
the enum and OID that would be needed, should you guys go down the
kernel signing route.
Luis
On Thu, Aug 27, 2015 at 11:38:58AM +0100, David Howells wrote:
> Luis R. Rodriguez <[email protected]> wrote:
>
> > "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
> >
> > 1.3.6.1.4.1.2312.16 Linux kernel
> > 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> > 1.3.6.1.4.1.2312.16.2.1 - firmwareName
> >
> > I take it you are referring to this?
>
> Yes.
>
> > If we follow this model we'd then need something like:
> >
> > 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
> >
> > That should mean each OID that has different file names would need to be
> > explicit about and have a similar entry on the registry. I find that pretty
> > redundant and would like to avoid that if possible.
>
> firmwareName is easy for people to understand - it's the name the kernel asks
> for and the filename of the blob. seLinuxPolicyName is, I think, a lot more
> tricky since a lot of people don't use SELinux, and most that do don't
> understand it (most people that use it aren't even really aware of it).
>
> If you can use the firmwareName as the SELinux/LSM key, I would suggest doing
> so - even if you dress it up as a path (/lib/firmware/<firmwareName>).
It seems we don't have to worry about it now, and perhaps SELinux folks might
go another route.
Luis
On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > Luis R. Rodriguez <[email protected]> wrote:
> >
> >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
> >>
> >> 1.3.6.1.4.1.2312.16 Linux kernel
> >> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> >> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
> >>
> >> I take it you are referring to this?
> >
> > Yes.
> >
> >> If we follow this model we'd then need something like:
> >>
> >> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
> >>
> >> That should mean each OID that has different file names would need to be
> >> explicit about and have a similar entry on the registry. I find that
> >> pretty redundant and would like to avoid that if possible.
> >
> > firmwareName is easy for people to understand - it's the name the kernel
> > asks for and the filename of the blob. seLinuxPolicyName is, I think, a
> > lot more tricky since a lot of people don't use SELinux, and most that do
> > don't understand it (most people that use it aren't even really aware of
> > it).
> >
> > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > doing so - even if you dress it up as a path
> > (/lib/firmware/<firmwareName>).
>
> In conversation with Mimi last week she was very keen on the model where
> we load modules & firmware in such a fashion that the kernel has access to
> the original inode -- by passing in a fd,
Sure, so let's be specific to ensure what Mimi needs is there. I though there
was work needed on modules but that seems covered and work then seems only
needed for kexec and SELinux policy files (and a review of other possible file
consumers in the kernel) for what you describe. I also went ahead and studied
areas where we can share code now as I was looking at this code now, and also
would like to recap on the idea of possibly just sharing the same LSM hook
for all "read this special file from the fs in the kernel" cases. Details below.
Fortnately the LSM hooks uses struct file and with this you can get the inode
with this:
struct inode *inode = file_inode(file);
For modules we have this LSM hook:
int (*kernel_module_from_file)(struct file *file);
This can be used for finit_module(). Its used as follows, the fd comes from
finit_module() syscall.
SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
{
...
err = copy_module_from_fd(fd, &info);
if (err)
return err;
...
}
static int copy_module_from_fd(int fd, struct load_info *info)
{
struct fd f = fdget(fd);
...
err = security_kernel_module_from_file(f.file);
if (err)
goto out;
}
For firmware we have this LSM hook:
int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);
> or in the firmware case by doing the fs lookup directly.
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
firmware API was also to allow for us to take a leap and let drivers
skip completely the usermode helper so we can then phase that code to the
only required remainign user: the dell-rbu driver. Anyway, once we have the
path built up we use it as follows.
static int fw_read_file(const char *path, void **_buf, size_t *_size)
{
struct file *file;
...
file = filp_open(path, O_RDONLY, 0);
if (IS_ERR(file))
return PTR_ERR(file);
...
rc = security_kernel_fw_from_file(file, buf, size);
if (rc)
goto err_buf;
...
}
I was under the impression that work was needed to add an LSM hook which would
grant the LSM access to the file specific data for modules but that's already
there with finit_module()! So Mimi needs is already there for modules as well
now.
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:
SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
unsigned long, cmdline_len, const char __user *, cmdline_ptr,
unsigned long, flags)
{
...
}
I noted earlier however that kexec is currently an x86 thing only though, and
Howells clarified that this is because we want kernel image signing as an
option (its a Kconfig option), and only PE supports a built-in signing method.
Its unclear to me who extends ELF and if its worthwhile to consider adding
support there for a signing method. Howells noted that there are rumours other
archs would support kexec, its unclear what they would use.
Even though kexec remains x86 specific an LSM for it should easily be possible
to add, but more on this below...
> So surely you have all the SELinux labelling you need?
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.
* 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.
* kexec
kexec works by reading files and setting up pointers for the different
segments it needs for bootup, it does this for both the kernel and initrd
if present. It however uses its own copy_file_from_fd() routine and no
surprise here, there's code that can be shared as well. We'd be using
a separate signature for kexec, so that'd be vetted on its own already.
It may be possible to share the same LSM hook here, again all parties
would just need to agree.
----
So conclusion:
After fw signing gets baked (or I'll do that as I work with the system data
helpers) there is possible work here to consolidate firmware's fw_read_file(),
module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel
tiny helper that gets it done right for all. If we really wanted to we could
also just use the same LSM hook for all, this hook would surely have the
struct file as Mimi wants as well. Unless I misunderstood things, at the
Linux security summit it seemed folks thought this was reasonable and
desirable. One of the gains then would be that the kernel can grow for
different use cases and files can be fetched as needed but we wouldn't have to
add yet-another-LSM hook for each new purpose, we'd just be sharing the same
fetch / LSM hook. Please discuss and let me know if this still stands, I'll
work towards any agreed upon direction with the fw signing code.
And again, there may other parts of the kernel that do similar work, just
as we found out about SELinux policy files. Those need to be identified
and studied separatley. I guess we can use grammar to hunt these down.
Luis
On Thu, Aug 27, 2015 at 3:36 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, Aug 26, 2015 at 10:35:19PM -0400, Paul Moore wrote:
>> On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez <[email protected]> wrote:
>> > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote:
>> > Now let's review the SELinux stuff before we jump back into firmware / system
>> > data stuff again as there is a joint criteria to consider for all of these.
>> > For other people's refrence the enum you quote above was added through your
>> > patch pending on linux-next:
>> >
>> > "PKCS#7: Appropriately restrict authenticated attributes and content type"
>> >
>> > Based on what Roberts seems to want to do for SELinux policy files it would
>> > seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is
>> > unique in the at it uses its own fs and uses a load trigger node (sel_load_ops)
>> > to kick off security_load_policy(data, count), so its not exactly a
>> > yet-another-API to read arbitrary files from the file system. Its policy files
>> > are also very distribution specific. Because of all this its not really
>> > suitable for /lib/firmware/ or sharing code even futher. It seems its a prime
>> > candidate already to make use of the system_verify_data() APIs you added David,
>> > provided the items below are taken care of as well.
>>
>> One thing to keep in mind is that not only are SELinux policy files
>> distribution specific, they are machine specific as administrators
>> can, and do, customize the policy for their usage. I really like the
>> idea of providing signed SELinux policies to the kernel but I question
>> how practical it will be for normal users/admins.
>
> Yeah that makes it harder. Possible but harder.
>
>> Some of the Machine Owner Key (MOK) work would likely be necessary for
>> signed SELinux policies to be even remotely practical.
>
> Matthew, Peter and Gary are Cc'd, so they can feel free to chime in.
>
> There are other alternatives as well:
>
> * Is there wide use of SELinux + IMA ? If so that may be another option.
I'm not aware of any large scale use of SELinux+IMA, although it is
doubtful that IMA will be of use for protecting the SELinux policy
since it is written into the kernel, the kernel doesn't load it
directly. There is also the issue that the SELinux userspace tends to
manipulate the policy such that the blob that is written into the
kernel isn't the same blob that is read from disk.
I imagine one could use IMA to protect the SELinux policy store, but
that isn't the same as protecting the binary security policy that is
written to the kernel.
--
paul moore
http://www.paul-moore.com
On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > > Luis R. Rodriguez <[email protected]> wrote:
> > >
> > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
> > >>
> > >> 1.3.6.1.4.1.2312.16 Linux kernel
> > >> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> > >> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
> > >>
> > >> I take it you are referring to this?
> > >
> > > Yes.
> > >
> > >> If we follow this model we'd then need something like:
> > >>
> > >> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
> > >>
> > >> That should mean each OID that has different file names would need to be
> > >> explicit about and have a similar entry on the registry. I find that
> > >> pretty redundant and would like to avoid that if possible.
> > >
> > > firmwareName is easy for people to understand - it's the name the kernel
> > > asks for and the filename of the blob. seLinuxPolicyName is, I think, a
> > > lot more tricky since a lot of people don't use SELinux, and most that do
> > > don't understand it (most people that use it aren't even really aware of
> > > it).
> > >
> > > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > > doing so - even if you dress it up as a path
> > > (/lib/firmware/<firmwareName>).
> >
> > In conversation with Mimi last week she was very keen on the model where
> > we load modules & firmware in such a fashion that the kernel has access to
> > the original inode -- by passing in a fd,
>
> Sure, so let's be specific to ensure what Mimi needs is there. I though there
> was work needed on modules but that seems covered and work then seems only
> needed for kexec and SELinux policy files (and a review of other possible file
> consumers in the kernel) for what you describe.
At last year's LSS linux-integrity status update, I mentioned 6
measurement/appraisal gaps, kernel modules (linux-3.7), firmware
(linux-3.17), kexec, initramfs, eBPF/seccomp and policies, that have
been or need to be addressed. Since then, a new kexec syscall, file
descriptor based, was upstreamed that appraises the image. Until we can
preserve the measurement list across kexec, it doesn't make sense to
measure the image just to have it thrown away. (skipping initramfs as
that isn't related to LSM hooks.) Lastly, measuring/appraising policies
(eg. IMA, SELinux, Smack, iptables/ebtables) or any other files consumed
by the kernel.
> I also went ahead and studied
> areas where we can share code now as I was looking at this code now, and also
> would like to recap on the idea of possibly just sharing the same LSM hook
> for all "read this special file from the fs in the kernel" cases. Details below.
>
> Fortnately the LSM hooks uses struct file and with this you can get the inode
> with this:
>
> struct inode *inode = file_inode(file);
>
> For modules we have this LSM hook:
>
> int (*kernel_module_from_file)(struct file *file);
>
> This can be used for finit_module(). Its used as follows, the fd comes from
> finit_module() syscall.
>
> SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
> {
> ...
> err = copy_module_from_fd(fd, &info);
> if (err)
> return err;
> ...
> }
>
> static int copy_module_from_fd(int fd, struct load_info *info)
> {
> struct fd f = fdget(fd);
> ...
> err = security_kernel_module_from_file(f.file);
> if (err)
> goto out;
> }
>
> For firmware we have this LSM hook:
>
> int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);
>
> > or in the firmware case by doing the fs lookup directly.
>
> 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
> firmware API was also to allow for us to take a leap and let drivers
> skip completely the usermode helper so we can then phase that code to the
> only required remainign user: the dell-rbu driver. Anyway, once we have the
> path built up we use it as follows.
>
> static int fw_read_file(const char *path, void **_buf, size_t *_size)
> {
> struct file *file;
> ...
> file = filp_open(path, O_RDONLY, 0);
> if (IS_ERR(file))
> return PTR_ERR(file);
> ...
> rc = security_kernel_fw_from_file(file, buf, size);
> if (rc)
> goto err_buf;
> ...
> }
>
> I was under the impression that work was needed to add an LSM hook which would
> grant the LSM access to the file specific data for modules but that's already
> there with finit_module()! So Mimi needs is already there for modules as well
> now.
>
> 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:
>
> SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> unsigned long, cmdline_len, const char __user *, cmdline_ptr,
> unsigned long, flags)
> {
> ...
> }
>
> I noted earlier however that kexec is currently an x86 thing only though, and
> Howells clarified that this is because we want kernel image signing as an
> option (its a Kconfig option), and only PE supports a built-in signing method.
> Its unclear to me who extends ELF and if its worthwhile to consider adding
> support there for a signing method. Howells noted that there are rumours other
> archs would support kexec, its unclear what they would use.
>
> Even though kexec remains x86 specific an LSM for it should easily be possible
> to add, but more on this below...
> > So surely you have all the SELinux labelling you need?
>
> 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 ?
Reading files from the kernel was frowned upon until recently. So both
SELinux and IMA, not sure about Smack, read the policy from userspace
into memory and pass it to the kernel. The 'file' defined here is not
the policy itself, but the selinuxfs file. 'buf' contains the policy.
I'm obviously in favor of such a change, as it would allow us to both
measure and appraise the policy.
> 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.
Instead of passing a buffer, the new syscalls are called with the file
descriptor. This allows the file to be both measured and appraised.
> 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.
Depending on the calling function, different validation requirements may
be desirable. I would include the calling function (existing hook).
For example, IMA-appraisal permits files to be hashed or signed.
Depending on the calling function, a hash might be acceptable for some,
but all of the hooks.
> * kexec
>
> kexec works by reading files and setting up pointers for the different
> segments it needs for bootup, it does this for both the kernel and initrd
> if present. It however uses its own copy_file_from_fd() routine and no
> surprise here, there's code that can be shared as well. We'd be using
> a separate signature for kexec, so that'd be vetted on its own already.
> It may be possible to share the same LSM hook here, again all parties
> would just need to agree.
>
> ----
>
> So conclusion:
>
> After fw signing gets baked (or I'll do that as I work with the system data
> helpers) there is possible work here to consolidate firmware's fw_read_file(),
> module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel
> tiny helper that gets it done right for all. If we really wanted to we could
> also just use the same LSM hook for all, this hook would surely have the
> struct file as Mimi wants as well. Unless I misunderstood things, at the
> Linux security summit it seemed folks thought this was reasonable and
> desirable. One of the gains then would be that the kernel can grow for
> different use cases and files can be fetched as needed but we wouldn't have to
> add yet-another-LSM hook for each new purpose, we'd just be sharing the same
> fetch / LSM hook. Please discuss and let me know if this still stands, I'll
> work towards any agreed upon direction with the fw signing code.
Thank you for coordinating this.
> And again, there may other parts of the kernel that do similar work, just
> as we found out about SELinux policy files. Those need to be identified
> and studied separatley. I guess we can use grammar to hunt these down.
I mentioned a few others above.
Mimi
On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <[email protected]> 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
http://www.paul-moore.com
> -----Original Message-----
> From: Paul Moore [mailto:[email protected]]
> Sent: Thursday, August 27, 2015 4:57 PM
> To: Luis R. Rodriguez
> Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lutomirski; Kees Cook;
> Roberts, William C; [email protected]; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; Vitaly Kuznetsov; Eric Paris;
> [email protected]; Stephen Smalley; Schaufler, Casey; Luis R. Rodriguez;
> Dmitry Kasatkin; Greg Kroah-Hartman; Peter Jones; Takashi Iwai; Ming Lei; Joey
> Lee; Vojtěch Pavlík; Kyle McMartin; Seth Forshee; Matthew Garrett; Johannes
> Berg
> Subject: Re: Linux Firmware Signing
>
> On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <[email protected]> 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.
Even triggered updates make sense, since you can at least have some form of trust
of where that binary policy came from.
> 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.
>
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. In the case of falling back to loading an unsigned blob, we could do it ala kernel
module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file.
If it fails on signature verification, we could still unpack it and pass it on. So you would want to
be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal.
We would also likely want to convey this state, the ability to change this setting to userspace in a
Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures,
And that my current policy file is in fact invalid or valid.
> --
> paul moore
> http://www.paul-moore.com
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
<[email protected]> wrote:
>> -----Original Message-----
>> From: Paul Moore [mailto:[email protected]]
>> Sent: Thursday, August 27, 2015 4:57 PM
>> To: Luis R. Rodriguez
>> Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lutomirski; Kees Cook;
>> Roberts, William C; [email protected]; linux-
>> [email protected]; [email protected];
>> [email protected]; [email protected]; Vitaly Kuznetsov; Eric Paris;
>> [email protected]; Stephen Smalley; Schaufler, Casey; Luis R. Rodriguez;
>> Dmitry Kasatkin; Greg Kroah-Hartman; Peter Jones; Takashi Iwai; Ming Lei; Joey
>> Lee; Vojtěch Pavlík; Kyle McMartin; Seth Forshee; Matthew Garrett; Johannes
>> Berg
>> Subject: Re: Linux Firmware Signing
>>
>> On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez <[email protected]> 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.
>
> 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. Policy
signatures are nice, I support their addition, but I believe they will
only be useful for certain usage scenarios and not really usable for
general systems.
>> 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.
>
> 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.
> In the case of falling back to loading an unsigned blob, we could do it ala kernel
> module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file.
It seems like we could aim to do a bit better than try-and-see, but
once again, I haven't looked at yet in detail so I'll defer to you
judgement at this point.
> If it fails on signature verification, we could still unpack it and pass it on. So you would want to
> be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal.
>
> We would also likely want to convey this state, the ability to change this setting to userspace in a
> Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures,
> And that my current policy file is in fact invalid or valid.
That sounds reasonable to me.
>> --
>> paul moore
>> http://www.paul-moore.com
--
paul moore
http://www.paul-moore.com
On Fri, Aug 28, 2015 at 11:20:10AM +0000, Roberts, William C wrote:
> > -----Original Message-----
> > From: Paul Moore [mailto:[email protected]]
> >
> > 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.
>
> Even triggered updates make sense, since you can at least have some form of trust
> of where that binary policy came from.
The problem that Paul describes stems from the requirement of such trust
needing post-boot / install / setup keys. It may be possible for an
environment to exist where there's a food chain that enables some CA's to
easily hand out keys to each install, but that seems impractical. This is why
Paul had mentioned the Machine Owner Key (MOK) thing.
> > 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.
> >
>
> 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)
Nitpick: its the system_verify_data() API, the fw signing stuff will make use
of this API as well.
> to unpack the blob.
Nitpick: to verify the data.
> In the case of falling back to loading an unsigned blob, we could do it ala kernel
> module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file.
> If it fails on signature verification, we could still unpack it and pass it on. So you would want to
> be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal.
>
> We would also likely want to convey this state, the ability to change this setting to userspace in a
> Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures,
> And that my current policy file is in fact invalid or valid.
Sure that would work. Its how the module stuff can work in permissive mode.
We'd embrace the same practice for permissive fw signing as well.
Luis
On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
> <[email protected]> wrote:
> > 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.
> > 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.
Luis
On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > > > Luis R. Rodriguez <[email protected]> wrote:
> > > >
> > > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > > >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good
> > > >>
> > > >> 1.3.6.1.4.1.2312.16 Linux kernel
> > > >> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> > > >> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
> > > >>
> > > >> I take it you are referring to this?
> > > >
> > > > Yes.
> > > >
> > > >> If we follow this model we'd then need something like:
> > > >>
> > > >> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
> > > >>
> > > >> That should mean each OID that has different file names would need to be
> > > >> explicit about and have a similar entry on the registry. I find that
> > > >> pretty redundant and would like to avoid that if possible.
> > > >
> > > > firmwareName is easy for people to understand - it's the name the kernel
> > > > asks for and the filename of the blob. seLinuxPolicyName is, I think, a
> > > > lot more tricky since a lot of people don't use SELinux, and most that do
> > > > don't understand it (most people that use it aren't even really aware of
> > > > it).
> > > >
> > > > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > > > doing so - even if you dress it up as a path
> > > > (/lib/firmware/<firmwareName>).
> > >
> > > In conversation with Mimi last week she was very keen on the model where
> > > we load modules & firmware in such a fashion that the kernel has access to
> > > the original inode -- by passing in a fd,
> >
> > Sure, so let's be specific to ensure what Mimi needs is there. I though there
> > was work needed on modules but that seems covered and work then seems only
> > needed for kexec and SELinux policy files (and a review of other possible file
> > consumers in the kernel) for what you describe.
Correct me if I'm wrong:
> At last year's LSS linux-integrity status update, I mentioned 6
> measurement/appraisal gaps, kernel modules (linux-3.7),
Done.
> firmware (linux-3.17),
I'm working on it, but as far as LSMs are concerned the LSM hook
is in place.
> kexec,
I'll note kexec has both a kernel and initramfs :) so just keep that
in mind. Technically it should vet for both. It seems we just need
an LSM hook there.
> initramfs,
Hm, what code path?
> eBPF/seccomp
Same here, where's this?
> and policies,
Which ones?
> that have
> been or need to be addressed. Since then, a new kexec syscall, file
> descriptor based, was upstreamed that appraises the image. Until we can
> preserve the measurement list across kexec,
I'm sorry I do not follow, can you elaborate on what you mean by this.
Its not clear to me what you mean by the measurement list. Do you mean
all the above items?
> it doesn't make sense to
> measure the image just to have it thrown away. (skipping initramfs as
> that isn't related to LSM hooks
Hrm, it can be, I mean at least for the kexec case its a fd that is passed
as part of the syscall, not sure of the other case you mentioned yet
as I haven't reviewed that code yet.
>.) Lastly, measuring/appraising policies
> (eg. IMA, SELinux, Smack, iptables/ebtables)
OK for each of these:
how do we load the data? Is that the full list? Note we should
be able to use grammar rules to hunt these down, I just haven't
sat down to write them but if this is important well we should.
> or any other files consumed
> by the kernel.
:D likewise
> > I also went ahead and studied
> > areas where we can share code now as I was looking at this code now, and also
> > would like to recap on the idea of possibly just sharing the same LSM hook
> > for all "read this special file from the fs in the kernel" cases. Details below.
> >
> > Fortnately the LSM hooks uses struct file and with this you can get the inode
> > with this:
> >
> > struct inode *inode = file_inode(file);
> >
> > For modules we have this LSM hook:
> >
> > int (*kernel_module_from_file)(struct file *file);
> >
> > This can be used for finit_module(). Its used as follows, the fd comes from
> > finit_module() syscall.
> >
> > SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
> > {
> > ...
> > err = copy_module_from_fd(fd, &info);
> > if (err)
> > return err;
> > ...
> > }
> >
> > static int copy_module_from_fd(int fd, struct load_info *info)
> > {
> > struct fd f = fdget(fd);
> > ...
> > err = security_kernel_module_from_file(f.file);
> > if (err)
> > goto out;
> > }
> >
> > For firmware we have this LSM hook:
> >
> > int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);
> >
> > > or in the firmware case by doing the fs lookup directly.
> >
> > 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
> > firmware API was also to allow for us to take a leap and let drivers
> > skip completely the usermode helper so we can then phase that code to the
> > only required remainign user: the dell-rbu driver. Anyway, once we have the
> > path built up we use it as follows.
> >
> > static int fw_read_file(const char *path, void **_buf, size_t *_size)
> > {
> > struct file *file;
> > ...
> > file = filp_open(path, O_RDONLY, 0);
> > if (IS_ERR(file))
> > return PTR_ERR(file);
> > ...
> > rc = security_kernel_fw_from_file(file, buf, size);
> > if (rc)
> > goto err_buf;
> > ...
> > }
> >
> > I was under the impression that work was needed to add an LSM hook which would
> > grant the LSM access to the file specific data for modules but that's already
> > there with finit_module()! So Mimi needs is already there for modules as well
> > now.
> >
> > 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:
> >
> > SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > unsigned long, cmdline_len, const char __user *, cmdline_ptr,
> > unsigned long, flags)
> > {
> > ...
> > }
> >
> > I noted earlier however that kexec is currently an x86 thing only though, and
> > Howells clarified that this is because we want kernel image signing as an
> > option (its a Kconfig option), and only PE supports a built-in signing method.
> > Its unclear to me who extends ELF and if its worthwhile to consider adding
> > support there for a signing method. Howells noted that there are rumours other
> > archs would support kexec, its unclear what they would use.
> >
> > Even though kexec remains x86 specific an LSM for it should easily be possible
> > to add, but more on this below...
>
> > > So surely you have all the SELinux labelling you need?
> >
> > 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 ?
>
> Reading files from the kernel was frowned upon until recently.
Well, to be clear there is an exception that was made to firmware and that
reads things from /lib/firmware. Then other than this we have modules, kexec.
SELinuxfs uses its own fs... not sure of others.
Note, CRDA does have a custom path and userspace reads it from a custom
path, then tosses it via netlink to the kernel, I'm changing that to just
use /lib/firmware/ and repurpose the firmware API calls as generic "system data"
fetchers. But this is just because we found it reasonable for us to deploy
the regulatory.bin file into /lib/firmware.
A review would be needed for the other users. People can't just assume they
can use /lib/firmware for everything. I mean, its used now even for CPU
microcode so... just keep that in mind ;)
> So both
> SELinux and IMA, not sure about Smack, read the policy from userspace
> into memory and pass it to the kernel.
That's how CRDA works too but we never implemetned a filesystem just to toss
things to the kernel, we however did have hooks for a netlink API to send it.
The userspace agent vetted for the file's integrity. We'll be switching this
to have the file vetted through a signature which we trust in the kernel.
What each of these do is up to them.
> The 'file' defined here is not
> the policy itself, but the selinuxfs file. 'buf' contains the policy.
> I'm obviously in favor of such a change, as it would allow us to both
> measure and appraise the policy.
Right, some technicalities in the implementation, but still its a file.
> > 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.
>
> Instead of passing a buffer, the new syscalls are called with the file
> descriptor. This allows the file to be both measured and appraised.
Right!
> > 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.
>
> Depending on the calling function, different validation requirements may
> be desirable. I would include the calling function (existing hook).
Seems reasonable to me. May require some macro hackery, not sure.
> For example, IMA-appraisal permits files to be hashed or signed.
> Depending on the calling function, a hash might be acceptable for some,
> but all of the hooks.
OK thanks will keep this in mind.
> > * kexec
> >
> > kexec works by reading files and setting up pointers for the different
> > segments it needs for bootup, it does this for both the kernel and initrd
> > if present. It however uses its own copy_file_from_fd() routine and no
> > surprise here, there's code that can be shared as well. We'd be using
> > a separate signature for kexec, so that'd be vetted on its own already.
> > It may be possible to share the same LSM hook here, again all parties
> > would just need to agree.
> >
> > ----
> >
> > So conclusion:
> >
> > After fw signing gets baked (or I'll do that as I work with the system data
> > helpers) there is possible work here to consolidate firmware's fw_read_file(),
> > module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel
> > tiny helper that gets it done right for all. If we really wanted to we could
> > also just use the same LSM hook for all, this hook would surely have the
> > struct file as Mimi wants as well. Unless I misunderstood things, at the
> > Linux security summit it seemed folks thought this was reasonable and
> > desirable. One of the gains then would be that the kernel can grow for
> > different use cases and files can be fetched as needed but we wouldn't have to
> > add yet-another-LSM hook for each new purpose, we'd just be sharing the same
> > fetch / LSM hook. Please discuss and let me know if this still stands, I'll
> > work towards any agreed upon direction with the fw signing code.
>
> Thank you for coordinating this.
Sure and thanks for the feedback.
> > And again, there may other parts of the kernel that do similar work, just
> > as we found out about SELinux policy files. Those need to be identified
> > and studied separatley. I guess we can use grammar to hunt these down.
>
> I mentioned a few others above.
It'd be good for us to do a further review to really vet *all* areas.
I am not convinced we've covered them all.
Luis
On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > > > > Luis R. Rodriguez <[email protected]> wrote:
> > > > In conversation with Mimi last week she was very keen on the model where
> > > > we load modules & firmware in such a fashion that the kernel has access to
> > > > the original inode -- by passing in a fd,
> > >
> > > Sure, so let's be specific to ensure what Mimi needs is there. I though there
> > > was work needed on modules but that seems covered and work then seems only
> > > needed for kexec and SELinux policy files (and a review of other possible file
> > > consumers in the kernel) for what you describe.
>
> Correct me if I'm wrong:
>
> > At last year's LSS linux-integrity status update, I mentioned 6
> > measurement/appraisal gaps, kernel modules (linux-3.7),
>
> Done.
>
> > firmware (linux-3.17),
>
> I'm working on it, but as far as LSMs are concerned the LSM hook
> is in place.
Right, the LSM hooks are used by LSMs, but also used by the integrity
subsystem, like here, to measure the file and verify the integrity of
the file.
int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
{
int ret;
ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
if (ret)
return ret;
return ima_fw_from_file(file, buf, size);
}
> > kexec,
>
> I'll note kexec has both a kernel and initramfs :) so just keep that
> in mind. Technically it should vet for both. It seems we just need
> an LSM hook there.
Distros build the initramfs on the target system, so the initramfs can't
come signed. But for those systems that the initramfs can be signed, we
should be verifying it.
> > initramfs,
>
> Hm, what code path?
In addition, the files within the initramfs should be measured and
verified. There isn't a need for a new hook, but for xattr support in
CPIO. I started adding that support last winter -
http://lwn.net/Articles/630101/ . Others have requested other changes,
not related to xattrs, before bumping the CPIO magic number. There
should be a discussion as to what else needs to be done.
> > eBPF/seccomp
>
> Same here, where's this?
>
> > and policies,
>
> Which ones?
>
> > that have
> > been or need to be addressed. Since then, a new kexec syscall, file
> > descriptor based, was upstreamed that appraises the image. Until we can
> > preserve the measurement list across kexec,
>
> I'm sorry I do not follow, can you elaborate on what you mean by this.
> Its not clear to me what you mean by the measurement list. Do you mean
> all the above items?
A measurement is a hash of the file which is stored in the measurement
list <securityfs>/ima/ascii_runtime_measurements and is used to extend
the TPM (eg. PCR 10). The measurement list, in conjunction with a
quote of the TPM PCRs, can be used to remotely detect whether a system
has been compromised.
David Safford's white paper "An Overview of the Linux Integrity
subsystem" -
http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf goes into details of the different terms and concepts. (The IMA wiki is dated.) There's also a ic2e paper titled "Scalable Attestation: a step toward secure and trusted cloud".
> > it doesn't make sense to
> > measure the image just to have it thrown away. (skipping initramfs as
> > that isn't related to LSM hooks
>
> Hrm, it can be, I mean at least for the kexec case its a fd that is passed
> as part of the syscall, not sure of the other case you mentioned yet
> as I haven't reviewed that code yet.
Right, in those situations that the initramfs can be signed, it should
be verified.
> >.) Lastly, measuring/appraising policies
> > (eg. IMA, SELinux, Smack, iptables/ebtables)
>
> OK for each of these:
>
> how do we load the data?
I'm not real happy about it, but since we can't break the existing ABI
of loading data into the kernel via a buffer, a stop gap method of
signing and verifying a buffer would be needed.
> Is that the full list? Note we should
> be able to use grammar rules to hunt these down, I just haven't
> sat down to write them but if this is important well we should.
>
> > or any other files consumed
> > by the kernel.
>
> :D likewise
< skip >
> It'd be good for us to do a further review to really vet *all* areas.
> I am not convinced we've covered them all.
Agreed
Mimi
On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> I'm not real happy about it, but since we can't break the existing ABI
> of loading data into the kernel via a buffer, a stop gap method of
> signing and verifying a buffer would be needed.
Actually I think we can. The usermode helper is already being phased
out.
--
dwmw2
On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote:
> On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote:
> > I'm not real happy about it, but since we can't break the existing ABI
> > of loading data into the kernel via a buffer, a stop gap method of
> > signing and verifying a buffer would be needed.
>
> Actually I think we can. The usermode helper is already being phased
> out.
Right. The discussion has moved beyond just firmware, but to policies
and other things the kernel consumes.
Mimi
On Fri, Aug 28, 2015 at 10:03 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote:
>> On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
>> <[email protected]> wrote:
>> > 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.
>> > 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.
--
paul moore
http://www.paul-moore.com