All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Cleaning up IMA
       [not found]       ` <1526657654.3404.17.camel@linux.vnet.ibm.com>
@ 2018-05-18 15:58         ` Petko Manolov
  2018-05-18 16:08           ` Mark Baushke
  0 siblings, 1 reply; 2+ messages in thread
From: Petko Manolov @ 2018-05-18 15:58 UTC (permalink / raw)
  To: Mimi Zohar; +Cc: Mark D. Baushke, Petko Manolov, linux-integrity

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@linux.vnet.ibm.com> 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.


		Petko

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Cleaning up IMA
  2018-05-18 15:58         ` Cleaning up IMA Petko Manolov
@ 2018-05-18 16:08           ` Mark Baushke
  0 siblings, 0 replies; 2+ messages in thread
From: Mark Baushke @ 2018-05-18 16:08 UTC (permalink / raw)
  To: Petko Manolov; +Cc: Mimi Zohar, Petko Manolov, linux-integrity


> On May 18, 2018, at 8:58 AM, Petko Manolov <petkan@nucleusys.com> 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@linux.vnet.ibm.com> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-05-18 16:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1526580423.3632.17.camel@linux.vnet.ibm.com>
     [not found] ` <92E32D97-B60A-4D75-AC9F-594F95E432B1@juniper.net>
     [not found]   ` <1526651759.3632.172.camel@linux.vnet.ibm.com>
     [not found]     ` <9298.1526652376@eng-mail01.juniper.net>
     [not found]       ` <1526657654.3404.17.camel@linux.vnet.ibm.com>
2018-05-18 15:58         ` Cleaning up IMA Petko Manolov
2018-05-18 16:08           ` Mark Baushke

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.