Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1329495
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: How to add additional blacklist entries? |
| Date | 2016-02-08 20:30 +0100 |
| Message-ID | <qZZFw-1eh-5@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qSCNK-78i-57@gated-at.bofh.it> <qY7xw-3G4-7@gated-at.bofh.it> <qZUwa-63L-17@gated-at.bofh.it> <qZWok-7it-59@gated-at.bofh.it> <qZXaH-7Ql-59@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, 2016-02-08 at 16:43 +0000, David Howells wrote: > Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: > > > > > Right, this patch makes the system blacklist keyring writable by > > > > userspace and removes the IMA blacklist. What I don't understand is how > > > > to add a key that is currently on the IMA keyring to the system > > > > blacklist? > > > > > > You can do this from userspace with "keyctl link". Admittedly, this > > > attaches the entire key to the blacklist keyring, not just the ID. But > > > that's basically what you're doing at the moment, right. > > > > Does this imply that the key already has to be loaded onto a keyring in > > order to link it to the blacklist? Currently the key doesn't need to > > be on the IMA keyring in order for it to be black listed. The cert can > > be verified, that it is signed by a key on the system trusted (or > > ima_mok) keyring(s), before directly being added to the IMA blacklist > > keyring. > > You can link from any key you have LINK permission on. Further, add_key() can > add directly. Oh, for some reason I thought the system blacklist keyring was limited to the new key type with just a description. I was able to add, but also remove a key from the system blacklist. I guess the KEY_FLAG_KEEP is not set on the system blacklist. > > > To simply list the SKID of the key you want to blacklist, another patch > > > will be required, but the question is as to what the interface should look > > > like. > > > > > > Let's start at the beginning. First of all, let me ask the following: > > > > > > (1) How is the key-to-be-blacklisted specified? A copy of the X.509 cert > > > to be blocked? A signed list of SKIDs to be blocked? A CRL? > > > > Similar to the TBScertificate hash list, there should be support for a > > SKIDs list, either in the same file or separately. > > Separately probably makes sense - and marking the blacklist keys with > something that says what is to be checked. > > > > (2) How is the blacklist addition to be verified? > > > > As I recall without going back and looking at the patches, you've > > defined a new key type for just the TBScertficate hash without a > > payload. > > Sort of. It carries a hash string as a description. One of the patches > matches this with the X.509 TBScertficate hash. I should look at adding > another patch to check the PE file content hash for kexec also. > > > Is it possible to do the equivalent for SKIDs? > > Yes. > > > In both cases, these new key type(s) would need to be signed by a key on the > > system keyring (now called the builtin keyring) for it to be added to the > > blacklist. > > I think you may have misunderstood the point of the question. Assuming we're > loading a SKID list from userspace, how do we validate the list? Is it > wrapped in an X.509 cert, a PKCS#7 message or is it a binary blob with an > associated signature? The keys being added to the IMA keyring are signed x509 certs (eg. openssl ca -ss_cert). It would be nice to be able to include the skid in the description, without a payload, and sign that. I have no idea if that Is possible or if it makes sense. I'm open to suggestions. > Or are you proposing the SKID list be built into the kernel at compile time > and not modifiable at runtime? No, we definitely want to be able to blacklist keys at run time. Mimi
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] David Howells <dhowells@redhat.com> - 2016-02-03 16:30 +0100
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-08 14:40 +0100
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] David Howells <dhowells@redhat.com> - 2016-02-08 15:00 +0100
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-08 16:10 +0100
How to add additional blacklist entries? David Howells <dhowells@redhat.com> - 2016-02-08 17:00 +0100
Re: How to add additional blacklist entries? Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-08 17:40 +0100
Re: How to add additional blacklist entries? David Howells <dhowells@redhat.com> - 2016-02-08 17:50 +0100
Re: How to add additional blacklist entries? Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-08 20:30 +0100
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] David Howells <dhowells@redhat.com> - 2016-02-08 16:00 +0100
Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-08 17:50 +0100
csiph-web