| Message ID | f9f2a5ab-a880-7131-d0ca-fb3b72571478@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Measure public keys of BuiltIn Trusted Keys | expand |
On Wed, 2019-06-05 at 17:16 -0700, Lakshmi wrote: > The motive behind this patch series is to measure the public key > of keys in BuiltIn_Trusted_Keys keyring to IMA log. > > The kernel could be built with the config parameter > CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled. > If this is done only those "IMA Signer Keys" that are signed by a key in > the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added > to the "IMA Keyring". > > In other words, "IMA Signer Keys" are attested by the "Trusted Keys" > on the client machines if the above config parameter is enabled. > > IMA will enumerate the keys in the Trusted Keys keyring, and measure > them in the IMA log. On file read, IMA will validate the signature of > the system files using "IMA Signer Key" present in "IMA Keyring". > > An attestation service would receive the "Trusted Keys" from > a trusted source (which is different from the client machines it is > attesting). The service would compare the Trusted Keys reported by > the client with the list of known Trusted Keys. A client would be > marked trusted by the service if and only if the keys reported > by the client are all trusted. > > Using the above approach the attestation service will be attesting > the "IMA Signer" while the clients attest the IMA Signature of > the system files. This enables the service to attest the client > machines by maintaining only a list of "Trusted Keys". These keys > change much less frequently than "IMA Signer Keys". It also frees > the service from having to maintain the "Hash of System Files" > which would change very frequently. This approach would significantly > reduce the maintenance cost of the service with respect to the data used > for attesting clients. Instead of measuring all the files in policy, Roberto's "digest lists" proposed patch set measures only "unknown" files. Why bother with all those messy measurements?! In your use case scenario, will the measurement list only contain the builtin and secondary keys? Mimi > > To achieve the above the patch series does the following: > - Adds a new method in asymmetric_key_subtype to query > the public key of the given key > - Enumerate the keys in "BuiltIn Trusted Keys" and measure > them to IMA log. > > Lakshmi (2): > Added a new interface method namely query_public_key to > asymmetric_key_subtype interface > Measure keys in BuiltIn Trusted Keys keyring > > Documentation/crypto/asymmetric-keys.txt | 1 + > certs/system_keyring.c | 7 ++ > crypto/asymmetric_keys/public_key.c | 7 ++ > crypto/asymmetric_keys/signature.c | 24 +++++++ > include/crypto/public_key.h | 1 + > include/keys/asymmetric-subtype.h | 3 + > include/keys/system_keyring.h | 9 +++ > include/linux/key.h | 32 +++++++++ > security/integrity/digsig.c | 58 +++++++++++++++++ > security/integrity/ima/Kconfig | 9 +++ > security/integrity/ima/ima_init.c | 62 ++++++++++++++++++ > security/integrity/integrity.h | 25 ++++++++ > security/keys/keyring.c | 82 ++++++++++++++++++++++++ > 13 files changed, 320 insertions(+) >
On 6/6/19 5:44 AM, Mimi Zohar wrote: > > Instead of measuring all the files in policy, Roberto's "digest lists" > proposed patch set measures only "unknown" files. Why bother with all > those messy measurements?! I agree. But in our use case scenario, we want the attestation service to know who signed the system files and leave the task of validating the file signature to the clients. Essentially, in our approach we are measuring the "signer". > In your use case scenario, will the measurement list only contain the builtin and secondary keys? > > Mimi In my implementation I am measuring the builtin keys. Since any key added to the secondary keyring also needs to be signed by a key in the builtin keyring, I feel measuring only "builtin keys" is sufficient. But I am open to the suggestion of measuring secondary keys as well. Please let me know if you think that is a must. Thanks, -lakshmi
On 6/5/2019 8:16 PM, Lakshmi wrote: > The motive behind this patch series is to measure the public key > of keys in BuiltIn_Trusted_Keys keyring to IMA log. I don't understand the motivation behind this proposal. Below, you explain what you do. Can you explain why? I.e., I don't see a problem with the proposal, but what is the benefit? > The kernel could be built with the config parameter > CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled. > If this is done only those "IMA Signer Keys" that are signed by a key in > the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added > to the "IMA Keyring". > > In other words, "IMA Signer Keys" are attested by the "Trusted Keys" > on the client machines if the above config parameter is enabled. > > IMA will enumerate the keys in the Trusted Keys keyring, and measure > them in the IMA log. On file read, IMA will validate the signature of > the system files using "IMA Signer Key" present in "IMA Keyring". > > An attestation service would receive the "Trusted Keys" from > a trusted source (which is different from the client machines it is > attesting). The service would compare the Trusted Keys reported by > the client with the list of known Trusted Keys. A client would be > marked trusted by the service if and only if the keys reported > by the client are all trusted. Why is this important? What is gained by measuring the keys on the built-in keyring? The IMA log already measures [a pointer to] the IMA keys used for signature verification. Why does the service care what keys were used to install the IMA keys? > Using the above approach the attestation service will be attesting > the "IMA Signer" while the clients attest the IMA Signature of > the system files. This enables the service to attest the client > machines by maintaining only a list of "Trusted Keys". These keys > change much less frequently than "IMA Signer Keys". It also frees > the service from having to maintain the "Hash of System Files" > which would change very frequently. This approach would significantly > reduce the maintenance cost of the service with respect to the data used > for attesting clients. I don't understand this reasoning. To me, there is a difference between signed files and trusted files. E.g., an old version may be signed, but it is no longer trusted. In other words, the service wants to know all files that have run, not just whether they are signed. Further, the service also wants to know files that were blocked from running, either because of no signature, a signature with an untrusted IMA key, or a bad signature. I.e., the service needs the entire IMA log, not just the keys used to install the keys used to locally verify the signatures. While the built-in keys may change less frequently that the IMA keys, both are likely to be stable. I.e., is this proposal to provide an additional security benefit, or is it to improve performance?
On 6/7/19 7:14 AM, Ken Goldman wrote: > > Why is this important? What is gained by measuring the keys on the > built-in keyring? The IMA log already measures [a pointer to] the > IMA keys used for signature verification. Why does the service care > what keys were used to install the IMA keys? By measuring the built-in keyring, the service knows whether or not the key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key validates the file signatures on the client, the built-in key validates the IMA key(s). By knowing what keys were used to install the IMA key(s) the service knows whether or not to trust the signature validation performed by IMA on the client. > > I don't understand this reasoning. > > To me, there is a difference between signed files and trusted files. > E.g., an old version may be signed, but it is no longer trusted. > > In other words, the service wants to know all files that have run, not > just whether they are signed. The service will receive the entire IMA log - the entries that show what system files were loaded, the IMA signature, etc. My change additionally provides measurement on the signer (which key(s) were used to install the keys in IMA keyring). Together this data enables the service to determine whether the files on the client were signed and who the signer is. The service can then decide whether the client is running files that are trusted. > > Further, the service also wants to know files that were blocked from > running, either because of no signature, a signature with an untrusted > IMA key, or a bad signature. I.e., the service needs the entire IMA > log, not just the keys used to install the keys used to locally verify > the signatures. Like I have stated above, the change I am making is adding more data (information on built-in keys) to what IMA log already provides". My proposal is not to replace the current IMA log with just data on "built-in keys". Also, want to clarify that we do not want the service to also locally verify the signatures. To do that the service needs to maintain the signed file hashes of all the files and all the versions of each of those files - That is an high overhead approach. Instead, we let the client do the signature validation and on the service just validate who signed those files. > > While the built-in keys may change less frequently that the IMA keys, > both are likely to be stable. I.e., is this proposal to provide an > additional security benefit, or is it to improve performance? The proposal enables the service to validate that the file signature of the files on the client were created by "trusted signer". So it provides additional security benefit and at the same time reduces the maintenance overhead in the service - by enabling it to just keep track of "Known good trusted keys" which change less frequently. I hope I have answered all of your questions\concerns. Thanks, -lakshmi
On 6/7/19 7:14 AM, Ken Goldman wrote: > On 6/5/2019 8:16 PM, Lakshmi wrote: >> The kernel could be built with the config parameter >> CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled. >> If this is done only those "IMA Signer Keys" that are signed by a key in >> the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added >> to the "IMA Keyring". >> >> In other words, "IMA Signer Keys" are attested by the "Trusted Keys" >> on the client machines if the above config parameter is enabled. >> >> IMA will enumerate the keys in the Trusted Keys keyring, and measure >> them in the IMA log. On file read, IMA will validate the signature of >> the system files using "IMA Signer Key" present in "IMA Keyring". >> >> An attestation service would receive the "Trusted Keys" from >> a trusted source (which is different from the client machines it is >> attesting). The service would compare the Trusted Keys reported by >> the client with the list of known Trusted Keys. A client would be >> marked trusted by the service if and only if the keys reported >> by the client are all trusted. > > Why is this important? What is gained by measuring the keys on the > built-in keyring? The IMA log already measures [a pointer to] the > IMA keys used for signature verification. Why does the service care > what keys were used to install the IMA keys? > >> Using the above approach the attestation service will be attesting >> the "IMA Signer" while the clients attest the IMA Signature of >> the system files. This enables the service to attest the client >> machines by maintaining only a list of "Trusted Keys". These keys >> change much less frequently than "IMA Signer Keys". It also frees >> the service from having to maintain the "Hash of System Files" >> which would change very frequently. This approach would significantly >> reduce the maintenance cost of the service with respect to the data used >> for attesting clients. > > I don't understand this reasoning. > > To me, there is a difference between signed files and trusted files. > E.g., an old version may be signed, but it is no longer trusted. > > In other words, the service wants to know all files that have run, not > just whether they are signed Thought I'd jump in this conversation to see if I can clarify what I see as the value of this patch set. At a certain point, keeping a list of all known-good (or known-bad) hashes becomes infeasible. We could probably disagree about at what scale this happens but I think we could agree that eventually this happens (let me know if you still disagree with this assertion). So at this point you likely need to rely on a few things: (1) is the file >= <known good version>. This allows you to forbid any kernel version before a vulnerability was fixed. (2) Was it signed with a good, trusted, production key. You can sort of do this today by using the keyid. The issues with this are (a) collision (though the chance may be pretty remote. I don't have the crypto expertise to make an empirical call on that) and (b) you need to know all the possible signing keys in the service. Again, once you cross a certain scale threshold, signing/deployment is so automated that the leaf key could change at any time, leaving your service in the dark about new keys. You could automatically add new trusted keys to the service but it depends on the service environment and how much you want to automate what the service trusts. So what does measuring the keyring do? It allows you to put long-lived trusted CAs in .builtin_trusted_keys. On the service if you trust the CA and you trust the running kernel to do the right thing during key enrollment, you can trust that loaded files are properly signed. > > Further, the service also wants to know files that were blocked from > running, either because of no signature, a signature with an untrusted > IMA key, or a bad signature. I.e., the service needs the entire IMA > log, not just the keys used to install the keys used to locally verify > the signatures. In UEFI measurements, the goal is usually to allow the service to decide what is important and what isn't. For example, UEFI measures the file hashes of efi binaries as well as the db (list of keys being used to validate efi signatures). The service is free to use one, both, or neither depending on its security model. Obviously Linux is not UEFI and "they do it in UEFI" is not a design justification by itself, just though I'd provide that as a frame of reference to explain the reasoning. > > While the built-in keys may change less frequently that the IMA keys, > both are likely to be stable. I.e., is this proposal to provide an > additional security benefit, or is it to improve performance? In my opinion the biggest benefit here is to improve manageability of keys. You can put trust in CAs (similar to what browsers do with SSL certs) and you don't need to update the service when leaf keys change, as they're bound to do. -Jordan
On 6/7/19 10:15 AM, Lakshmi wrote: > On 6/7/19 7:14 AM, Ken Goldman wrote: > >> >> Why is this important? What is gained by measuring the keys on the >> built-in keyring? The IMA log already measures [a pointer to] the >> IMA keys used for signature verification. Why does the service care >> what keys were used to install the IMA keys? > > By measuring the built-in keyring, the service knows whether or not the > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key > validates the file signatures on the client, the built-in key validates > the IMA key(s). > > By knowing what keys were used to install the IMA key(s) the service > knows whether or not to trust the signature validation performed by IMA > on the client. Hi Ken\Mimi, Please let me know if you have more questions\concerns about this approach. If the high level design is acceptable, please review the code changes and provide feedback\comments. Thanks, -lakshmi
On Fri, 2019-06-07 at 10:15 -0700, Lakshmi wrote: > On 6/7/19 7:14 AM, Ken Goldman wrote: > > > > > Why is this important? What is gained by measuring the keys on the > > built-in keyring? The IMA log already measures [a pointer to] the > > IMA keys used for signature verification. Why does the service care > > what keys were used to install the IMA keys? > > By measuring the built-in keyring, the service knows whether or not the > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key > validates the file signatures on the client, the built-in key validates > the IMA key(s). > > By knowing what keys were used to install the IMA key(s) the service > knows whether or not to trust the signature validation performed by IMA > on the client. > > > > > I don't understand this reasoning. > > > > To me, there is a difference between signed files and trusted files. > > E.g., an old version may be signed, but it is no longer trusted. > > > In other words, the service wants to know all files that have run, not > > just whether they are signed. > > The service will receive the entire IMA log - the entries that show what > system files were loaded, the IMA signature, etc. My change additionally > provides measurement on the signer (which key(s) were used to install > the keys in IMA keyring). Together this data enables the service to > determine whether the files on the client were signed and who the signer > is. The service can then decide whether the client is running files that > are trusted. > > > > > Further, the service also wants to know files that were blocked from > > running, either because of no signature, a signature with an untrusted > > IMA key, or a bad signature. I.e., the service needs the entire IMA > > log, not just the keys used to install the keys used to locally verify > > the signatures. > > Like I have stated above, the change I am making is adding more data > (information on built-in keys) to what IMA log already provides". > > My proposal is not to replace the current IMA log with just data on > "built-in keys". > > Also, want to clarify that we do not want the service to also locally > verify the signatures. To do that the service needs to maintain the > signed file hashes of all the files and all the versions of each of > those files - That is an high overhead approach. > > Instead, we let the client do the signature validation and on the > service just validate who signed those files. > > > > > While the built-in keys may change less frequently that the IMA keys, > > both are likely to be stable. I.e., is this proposal to provide an > > additional security benefit, or is it to improve performance? > > The proposal enables the service to validate that the file signature of > the files on the client were created by "trusted signer". So it provides > additional security benefit and at the same time reduces the maintenance > overhead in the service - by enabling it to just keep track of "Known > good trusted keys" which change less frequently. > > I hope I have answered all of your questions\concerns. The design of IMA from the very beginning has been to allow the system owner to decide which keys to trust. This is the reason that the root of trust pivots from the pre-boot keys to the keys embedded in the Linux kernel. When software packages contain both the file data and file signatures, the system owner will be able to pick and choose which public keys to sign and load onto the IMA keyring. This patch set might not be limiting which public keys may be loaded onto the builtin/secondary keyrings, but by virtue of including this information in the measurement list, the attestation service (eg. TNC) will be able to deny access. IMA walks a fine line in enforcing and measuring file integrity. This patch set breaches that fine line and by so doing, brings back the fears of trusted computing. Mimi
On Tue, 2019-06-11 at 08:22 -0400, Mimi Zohar wrote: > On Fri, 2019-06-07 at 10:15 -0700, Lakshmi wrote: > > On 6/7/19 7:14 AM, Ken Goldman wrote: > > > > > > > > Why is this important? What is gained by measuring the keys on the > > > built-in keyring? The IMA log already measures [a pointer to] the > > > IMA keys used for signature verification. Why does the service care > > > what keys were used to install the IMA keys? > > > > By measuring the built-in keyring, the service knows whether or not the > > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key > > validates the file signatures on the client, the built-in key validates > > the IMA key(s). > > > > By knowing what keys were used to install the IMA key(s) the service > > knows whether or not to trust the signature validation performed by IMA > > on the client. > > > > > > > > I don't understand this reasoning. > > > > > > To me, there is a difference between signed files and trusted files. > > > E.g., an old version may be signed, but it is no longer trusted. > > > > In other words, the service wants to know all files that have run, not > > > just whether they are signed. > > > > The service will receive the entire IMA log - the entries that show what > > system files were loaded, the IMA signature, etc. My change additionally > > provides measurement on the signer (which key(s) were used to install > > the keys in IMA keyring). Together this data enables the service to > > determine whether the files on the client were signed and who the signer > > is. The service can then decide whether the client is running files that > > are trusted. > > > > > > > > Further, the service also wants to know files that were blocked from > > > running, either because of no signature, a signature with an untrusted > > > IMA key, or a bad signature. I.e., the service needs the entire IMA > > > log, not just the keys used to install the keys used to locally verify > > > the signatures. > > > > Like I have stated above, the change I am making is adding more data > > (information on built-in keys) to what IMA log already provides". > > > > My proposal is not to replace the current IMA log with just data on > > "built-in keys". > > > > Also, want to clarify that we do not want the service to also locally > > verify the signatures. To do that the service needs to maintain the > > signed file hashes of all the files and all the versions of each of > > those files - That is an high overhead approach. > > > > Instead, we let the client do the signature validation and on the > > service just validate who signed those files. > > > > > > > > While the built-in keys may change less frequently that the IMA keys, > > > both are likely to be stable. I.e., is this proposal to provide an > > > additional security benefit, or is it to improve performance? > > > > The proposal enables the service to validate that the file signature of > > the files on the client were created by "trusted signer". So it provides > > additional security benefit and at the same time reduces the maintenance > > overhead in the service - by enabling it to just keep track of "Known > > good trusted keys" which change less frequently. > > > > I hope I have answered all of your questions\concerns. > > The design of IMA from the very beginning has been to allow the system > owner to decide which keys to trust. This is the reason that the root > of trust pivots from the pre-boot keys to the keys embedded in the > Linux kernel. When software packages contain both the file data and > file signatures, the system owner will be able to pick and choose > which public keys to sign and load onto the IMA keyring. > > This patch set might not be limiting which public keys may be loaded > onto the builtin/secondary keyrings, but by virtue of including this > information in the measurement list, the attestation service (eg. TNC) > will be able to deny access. IMA walks a fine line in enforcing and > measuring file integrity. This patch set breaches that fine line and > by so doing, brings back the fears of trusted computing. Many attempts over the years were made to update grub to support secure & trusted boot. Richard Stallman (grudgingly) added the secure boot callbacks, which are also being used for trusted boot. The code to actually do the signature verification though, as far as I'm aware, is still not part of grub. It also took a really long time and effort to convince Stallman that TPMs aren't totally bad. He's added an addendum to the wiki.[1] Let's try not to upset Stallman too much. Mimi [1] https://www.gnu.org/philosophy/can-you-trust.en.html
On 6/11/19 10:13 AM, Mimi Zohar wrote: >> >> The design of IMA from the very beginning has been to allow the system >> owner to decide which keys to trust. This is the reason that the root >> of trust pivots from the pre-boot keys to the keys embedded in the >> Linux kernel. When software packages contain both the file data and >> file signatures, the system owner will be able to pick and choose >> which public keys to sign and load onto the IMA keyring. >> >> This patch set might not be limiting which public keys may be loaded >> onto the builtin/secondary keyrings, but by virtue of including this >> information in the measurement list, the attestation service (eg. TNC) >> will be able to deny access. IMA walks a fine line in enforcing and >> measuring file integrity. This patch set breaches that fine line and >> by so doing, brings back the fears of trusted computing. I don't understand why measuring the keyring is more restrictive. Currently the signature of a file can already be measured. This means that the service can maintain a list of allowable keys and see if the files are signed with any of those keys. So effectively it is already possible for a service to deny access to the machine based on the keys it trusts. I also think validating the keys in the keyring is less restrictive than file-hash validation. You can say "I trust any file that the signer trusts". In file-hash validation you're saying "I only trust the files that I trust". > > Many attempts over the years were made to update grub to support > secure & trusted boot. Richard Stallman (grudgingly) added the secure > boot callbacks, which are also being used for trusted boot. The code > to actually do the signature verification though, as far as I'm aware, > is still not part of grub. > > It also took a really long time and effort to convince Stallman that > TPMs aren't totally bad. He's added an addendum to the wiki.[1] > Let's try not to upset Stallman too much. I do understand the desire to avoid taking a step backward by pushing too hard. As I said above, I don't see this as more restrictive than the existing measurements. But you have more understanding of the history here so let me know if I'm missing something. -Jordan > > Mimi > > [1] https://www.gnu.org/philosophy/can-you-trust.en.html >
On Wed, 2019-06-12 at 09:47 -0700, Jordan Hand wrote:
> I don't understand why measuring the keyring is more restrictive.
It's more restrictive because of which keyring you're measuring.
You're not measuring the IMA keyring, but the builtin keyring.
Mimi
On 6/7/2019 1:15 PM, Lakshmi wrote: > On 6/7/19 7:14 AM, Ken Goldman wrote: > >> >> Why is this important? What is gained by measuring the keys on the >> built-in keyring? The IMA log already measures [a pointer to] the >> IMA keys used for signature verification. Why does the service care >> what keys were used to install the IMA keys? > > By measuring the built-in keyring, the service knows whether or not the > key(s) in "IMA keyring" are indeed trusted or not. So while the IMA key > validates the file signatures on the client, the built-in key validates > the IMA key(s). How will it know that? It will know about the keys in the built-in keyring, but how does that say whether an IMA key is trusted? > > By knowing what keys were used to install the IMA key(s) the service > knows whether or not to trust the signature validation performed by IMA > on the client. How does that happen? In order to trust the IMA validation, it has to attest to the code doing the validation, and to the IMA keys. It already knows which IMA keys were used from the IMA log, assuming the IMA code is attested. > The service will receive the entire IMA log - the entries that show what > system files were loaded, the IMA signature, etc. My change additionally > provides measurement on the signer (which key(s) were used to install > the keys in IMA keyring). Together this data enables the service to > determine whether the files on the client were signed and who the signer > is. The service can then decide whether the client is running files that > are trusted. How does knowing the keys on the built-in keyring tell which files were signed? How does it tell who the signer is? That information (whether signed and what signed it) comes from the IMA log, right? How would your design help to know whether the files being run are trusted? I think that has to come out-of-band. E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is, but I may not trust anything older than libfoo.2.0.0. > Like I have stated above, the change I am making is adding more data > (information on built-in keys) to what IMA log already provides". Understood. I'm trying to learn the usefulness of that data. > > My proposal is not to replace the current IMA log with just data on > "built-in keys". > > Also, want to clarify that we do not want the service to also locally > verify the signatures. To do that the service needs to maintain the > signed file hashes of all the files and all the versions of each of > those files - That is an high overhead approach. Doesn't it needs those hashes anyway, to determine whether the file is trusted. To me "signed with a trusted key" does not equal "trusted". > The proposal enables the service to validate that the file signature of > the files on the client were created by "trusted signer". So it provides > additional security benefit and at the same time reduces the maintenance > overhead in the service - by enabling it to just keep track of "Known > good trusted keys" which change less frequently. We already know who signed from the IMA keys in the IMA log. How does knowing who was authorized to install IMA keys help? The attestor still has to know out of band which IMA keys to trust, and which files to trust.
On 6/17/19 10:04 AM, Ken Goldman wrote: > How will it know that? It will know about the keys in the built-in > keyring, but how does that say whether an IMA key is trusted? The parameter CONFIG_INTEGRITY_TRUSTED_KEYRING is enabled so that key(s) added to the IMA keyring must be signed by a key in the system trusted keyring. So by knowing what keys are present in the "Built-In Trusted Keyring", we can know if the IMA keys are trusted or not. >> By knowing what keys were used to install the IMA key(s) the service >> knows whether or not to trust the signature validation performed by >> IMA on the client. > > How does that happen? > > In order to trust the IMA validation, it has to attest to the code doing > the validation, and to the IMA keys. > > It already knows which IMA keys were used from the IMA log, assuming the > IMA code is attested. Yes - from the IMA log the service knows which IMA keys were used. And, by knowing the keys in built-in trusted keyring, the service can know whether those IMA keys are trusted (because the IMA keys have to be signed by the key(s) in built-in trusted keyring: by enabling CONFIG_INTEGRITY_TRUSTED_KEYRING). Since, the built-in keys change much less often than the IMA keys, it is much less maintenance overhead in the service to attest the built-in keys compared to attesting the IMA keys. Due to the requirement that the IMA keys must be signed by built-in key, attesting the built-in key effectively attests the IMA keys as well. > How does knowing the keys on the built-in keyring tell which files were > signed? How does it tell who the signer is? > > That information (whether signed and what signed it) comes from the IMA > log, right? The IMA log tells the service which files were signed and which IMA key was used to sign those files. My proposal does not alter (remove) any data that is currently supported in the IMA log. It is only adding more information in the IMA log - the information on the signer of the IMA signer key(s). > How would your design help to know whether the files being run are > trusted? I think that has to come out-of-band. > > E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is, > but I may not trust anything older than libfoo.2.0.0. You are right - the fact that file older than, for example, libfoo 2.0.0 is trusted or not is not something my proposal covers. That is not the goal of this proposal. IMA log currently just conveys libfoo.1.5.6 is signed and provides information on the signer. Whether that version is trusted or not needs to be verified by the service outside of IMA. >> Like I have stated above, the change I am making is adding more data >> (information on built-in keys) to what IMA log already provides". > > Understood. I'm trying to learn the usefulness of that data. My proposal is adding information on the signer of the IMA signer key - that signer information is in the "Built-In Trusted Keys". That data, in addition to the current IMA log, provides information to the service to determine if the IMA keys used by the clients are trusted or not. > Doesn't it needs those hashes anyway, to determine whether the file is > trusted. To me "signed with a trusted key" does not equal "trusted". I agree - a file that has valid signature may not be trusted because that version of the file was, for instance, buggy. The goal of my proposal is not to help the service determine whether a file is trusted or not - that has to be done outside of IMA. The goal of my proposal is to convey whether the file was signed with a trusted key. > We already know who signed from the IMA keys in the IMA log. > > How does knowing who was authorized to install IMA keys help? The > attestor still has to know out of band which IMA keys to trust, and > which files to trust. By building the kernel with CONFIG_INTEGRITY_TRUSTED_KEYRING we are mandating that the IMA key is signed by built-in key. So by knowing who authorized (signed) the IMA key, the service is able to know whether to trust the IMA key or not. Information on the IMA key is already available in the IMA log. But since IMA keys change much more frequently than the "Built-In Keys", it is more overhead for the service to keep track of all valid IMA keys compared to doing the same for "Built-In keys". Hence my proposal to include the "Built-In keys" in the IMA measurement. Thanks, -lakshmi
On Mon, Jun 17, 2019 at 10:05 AM Ken Goldman <kgold@linux.ibm.com> wrote: > On 6/7/2019 1:15 PM, Lakshmi wrote: > > By knowing what keys were used to install the IMA key(s) the service > > knows whether or not to trust the signature validation performed by IMA > > on the client. > > How does that happen? > > In order to trust the IMA validation, it has to attest to the code doing > the validation, and to the IMA keys. If you can assert that all code you've signed with your Secure Boot signing key is trusted, and that all keys that are embedded within code that's signed with your Secure Boot signing key are trusted, and that all keys signed with those keys are trusted, then you just need a mechanism to measure each component of that chain and attest to it. This is, as an example, the default Bitlocker policy under Windows - rather than seal the disk encryption secret to the full set of PCR values, the secret is sealed to PCR7. If a non-Windows bootloader is inserted into the boot process the PCR7 measurement will change (due to it being signed with a different certificate) and the unsealing will fail. Since Microsoft can assert that they will never sign something that they don't trust, this avoids having to re-seal the secret every time they update the bootloader. > E.g., I can know that libfoo.so.1.2.3 is signed and who the signer is, > but I may not trust anything older than libfoo.2.0.0. If you want to construct more complex policies then you need to examine more information :) This approach doesn't work for your case, but if the policy concern is "I want to ensure that all code run on this system came through my build pipeline" then you don't need to look at individual signatures.
On 6/10/2019 12:57 PM, Jordan Hand wrote: > > Thought I'd jump in this conversation to see if I can clarify what I see > as the value of this patch set. > > At a certain point, keeping a list of all known-good (or known-bad) > hashes becomes infeasible. We could probably disagree about at what > scale this happens but I think we could agree that eventually this > happens (let me know if you still disagree with this assertion). So at > this point you likely need to rely on a few things: I've seen large systems with 60,000 measurements. Even if that goes to 100,000, *10 for bad measurements, and *10 for future expansion, that's only 10M, or 320 mbytes. That's pennies of disk space. > > (1) is the file >= <known good version>. This allows you to forbid any > kernel version before a vulnerability was fixed. Perhaps, but one might also exclude a newer version, either because of a regression, a certification, etc. > > (2) Was it signed with a good, trusted, production key. > > You can sort of do this today by using the keyid. The issues with this > are (a) collision (though the chance may be pretty remote. I don't have > the crypto expertise to make an empirical call on that) and (b) you need > to know all the possible signing keys in the service. The 4 byte key id was probably a long term mistake, but can be fixed. Today, a collision is remote. Even then, just try both keys. Nothing breaks. > > Again, once you cross a certain scale threshold, signing/deployment is > so automated that the leaf key could change at any time, leaving your > service in the dark about new keys. You could automatically add new > trusted keys to the service but it depends on the service environment > and how much you want to automate what the service trusts. > > So what does measuring the keyring do? It allows you to put long-lived > trusted CAs in .builtin_trusted_keys. On the service if you trust the CA > and you trust the running kernel to do the right thing during key > enrollment, you can trust that loaded files are properly signed. This is my gap in understanding. Even if I somewhat trust the keys on the built-in keyring, I may not trust every key on the IMA keyring. I may trust the kernel that ran at the time the key was enrolled, but I don't trust the one that's currently running until I attest. Or, are all the keys on both keyrings erased before any kernel SW update? I don't think so.
On 6/18/19 10:31 AM, Ken Goldman wrote: > On 6/10/2019 12:57 PM, Jordan Hand wrote: >> >> Thought I'd jump in this conversation to see if I can clarify what I >> see as the value of this patch set. >> >> At a certain point, keeping a list of all known-good (or known-bad) >> hashes becomes infeasible. We could probably disagree about at what >> scale this happens but I think we could agree that eventually this >> happens (let me know if you still disagree with this assertion). So at >> this point you likely need to rely on a few things: > > I've seen large systems with 60,000 measurements. Even if that goes to > 100,000, *10 for bad measurements, and *10 for future expansion, that's > only 10M, or 320 mbytes. That's pennies of disk space. Ah, so I'm not really worried about disk space/file size. I'm worried about the need to update the service every time a new key is used to sign something. Lets say the people who are maintaining the attestation service (Team A) are different from the people writing/signing the code to run on the client (Team B). The problem is that Team A has to take an update whenever a new signing key is used. And rolling leaf keys is often an automatic process so Team B may not even know exactly when a new leaf key is used. They just know its the same CA. And now as Team A, I may trust code as long as its signed by 1 of 10 different sources. My concern is more that the process of keeping track of these leaf keys doesn't scale. This is where having a shared/static CA shines (as it does in other PKI infrastructures like TLS). > >> >> (1) is the file >= <known good version>. This allows you to forbid any >> kernel version before a vulnerability was fixed. > > Perhaps, but one might also exclude a newer version, either because of a > regression, a certification, etc. > >> >> (2) Was it signed with a good, trusted, production key. >> >> You can sort of do this today by using the keyid. The issues with this >> are (a) collision (though the chance may be pretty remote. I don't >> have the crypto expertise to make an empirical call on that) and (b) >> you need to know all the possible signing keys in the service. > > The 4 byte key id was probably a long term mistake, but can be fixed. > Today, a collision is remote. Even then, just try both keys. Nothing > breaks. > >> >> Again, once you cross a certain scale threshold, signing/deployment is >> so automated that the leaf key could change at any time, leaving your >> service in the dark about new keys. You could automatically add new >> trusted keys to the service but it depends on the service environment >> and how much you want to automate what the service trusts. >> >> So what does measuring the keyring do? It allows you to put long-lived >> trusted CAs in .builtin_trusted_keys. On the service if you trust the >> CA and you trust the running kernel to do the right thing during key >> enrollment, you can trust that loaded files are properly signed. > > This is my gap in understanding. > > Even if I somewhat trust the keys on the built-in keyring, I may not > trust every key on the IMA keyring. Its a different policy than is maybe used today in IMA, but often it is the case that I want indirect trust. I (Party A) trust Party B. Party B trusts parties C, D, and E. And long as party B trusts them, then party A can also trust C, D, and E. It allows for a service to trust any code that chains to a CA, but not trust any code that doesn't, in cases where the service may not know the exact hashes or leaf keys it should trust. > > I may trust the kernel that ran at the time the key was enrolled, but I > don't trust the one that's currently running until I attest. Or, are > all the keys on both keyrings erased before any kernel SW update? I > don't think so. On a cold boot, the keys would be re-enrolled. I'm not sure about the kexec case. But as long as you carry-forward the measurement log across kexec, you can attest to the whole chain (this assumes TPM-based attestation). And if you don't carry forward the measurements, there are some other server side things you can do to reconstruct the PCR state. But I think that's a bit out of scope for this discussion. -Jordan
On 6/18/19 10:52 AM, Jordan Hand wrote: Hi Ken, Did we (Jordan and I) address your concerns related to this patch set? If you have more questions\concerns I'll be happy to respond. Thanks, -lakshmi
On 6/25/19 1:27 PM, Lakshmi wrote: > On 6/18/19 10:52 AM, Jordan Hand wrote: > > Hi Ken, > > Did we (Jordan and I) address your concerns related to this patch set? > > If you have more questions\concerns I'll be happy to respond. > > Thanks, > -lakshmi Hi Ken\Mimi, I wanted to check again - Did Jordan and I address your concerns? Do you have more questions\concerns related to this patch set? Please let me know. Thanks, -lakshmi
On Tue, 2019-07-16 at 09:33 -0700, Lakshmi wrote: > Hi Ken\Mimi, > > I wanted to check again - Did Jordan and I address your concerns? > Do you have more questions\concerns related to this patch set? > > Please let me know. I made my thoughts on this subject pretty clear. Mimi
On 7/16/19 10:51 AM, Mimi Zohar wrote: > On Tue, 2019-07-16 at 09:33 -0700, Lakshmi wrote: >> Hi Ken\Mimi, >> >> I wanted to check again - Did Jordan and I address your concerns? >> Do you have more questions\concerns related to this patch set? >> >> Please let me know. > > I made my thoughts on this subject pretty clear. > > Mimi > Thanks Mimi. -lakshmi
The motive behind this patch series is to measure the public key of keys in BuiltIn_Trusted_Keys keyring to IMA log. The kernel could be built with the config parameter CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY enabled. If this is done only those "IMA Signer Keys" that are signed by a key in the "BuiltIn Trusted Keys" or the "Secondary Trusted Keys" can be added to the "IMA Keyring". In other words, "IMA Signer Keys" are attested by the "Trusted Keys" on the client machines if the above config parameter is enabled. IMA will enumerate the keys in the Trusted Keys keyring, and measure them in the IMA log. On file read, IMA will validate the signature of the system files using "IMA Signer Key" present in "IMA Keyring". An attestation service would receive the "Trusted Keys" from a trusted source (which is different from the client machines it is attesting). The service would compare the Trusted Keys reported by the client with the list of known Trusted Keys. A client would be marked trusted by the service if and only if the keys reported by the client are all trusted. Using the above approach the attestation service will be attesting the "IMA Signer" while the clients attest the IMA Signature of the system files. This enables the service to attest the client machines by maintaining only a list of "Trusted Keys". These keys change much less frequently than "IMA Signer Keys". It also frees the service from having to maintain the "Hash of System Files" which would change very frequently. This approach would significantly reduce the maintenance cost of the service with respect to the data used for attesting clients. To achieve the above the patch series does the following: - Adds a new method in asymmetric_key_subtype to query the public key of the given key - Enumerate the keys in "BuiltIn Trusted Keys" and measure them to IMA log. Lakshmi (2): Added a new interface method namely query_public_key to asymmetric_key_subtype interface Measure keys in BuiltIn Trusted Keys keyring Documentation/crypto/asymmetric-keys.txt | 1 + certs/system_keyring.c | 7 ++ crypto/asymmetric_keys/public_key.c | 7 ++ crypto/asymmetric_keys/signature.c | 24 +++++++ include/crypto/public_key.h | 1 + include/keys/asymmetric-subtype.h | 3 + include/keys/system_keyring.h | 9 +++ include/linux/key.h | 32 +++++++++ security/integrity/digsig.c | 58 +++++++++++++++++ security/integrity/ima/Kconfig | 9 +++ security/integrity/ima/ima_init.c | 62 ++++++++++++++++++ security/integrity/integrity.h | 25 ++++++++ security/keys/keyring.c | 82 ++++++++++++++++++++++++ 13 files changed, 320 insertions(+)