> On May 18, 2018, at 8:58 AM, Petko Manolov <petkan@xxxxxxxxxxxxx> wrote:
>
> On 18-05-18 11:34:14, Mimi Zohar wrote:
>> On Fri, 2018-05-18 at 07:06 -0700, Mark D. Baushke wrote:
>>> Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes:
>>>
>>>> On Fri, 2018-05-18 at 13:44 +0000, Mark Baushke wrote:
>>>>> Hi Mimi,
>>>>>
>>>>> I see that Petko has already provide the answer and an updated patch.
>>>>>
>>>>> I was off-line most of yesterday, and am only now catching up on email.
>>>>>
>>>>> To confirm, yes, we are still using the ima_update_policy() code.
>>
>> Updating the policy wasn't the question. It was about using the IMA blacklist,
>> as opposed to the system blacklist.
>
> The system-wide blacklist is populated at build time only. This means that you
> need kernel change if you want to revoke a certificate, which is sub-optimal.
> To be useful for us it should be able to accept imports at run-time.
>
> Until the system-wide blacklist keyring doesn't have this functionality i
> suggest that we keep .ima_blacklist around.
>
Ahhh... yes. One of the things we allow our customers to do is choose to revoke our development keys so that only production signed images will run on their networks if they wish to make use of that feature.
As such, adding to the .ima_blacklist is used and will continue to be useful.
We typically make that decision before we enter multi-user mode on reboot...
Enjoy!
-- Mark
