On 15-10-21 07:52:20, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 14:29 +0300, Petko Manolov wrote:
> > On 15-10-21 07:22:58, Mimi Zohar wrote:
> > > On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> > > > Mimi Zohar wrote:
>
> > > Adding the semantics at the keyring level would be better t
On 15-10-21 12:49:19, David Howells wrote:
> Petko Manolov wrote:
>
> > > > As far as i know there is no concept of write-once to a keyring in the
> > > > kernel. David will correct me if i am wrong. I wonder how hard would
> > > > it be to add such functionality, in case it is missing?
> > >
On Wed, 2015-10-21 at 14:29 +0300, Petko Manolov wrote:
> On 15-10-21 07:22:58, Mimi Zohar wrote:
> > On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> > > Mimi Zohar wrote:
> > Adding the semantics at the keyring level would be better than at the
> > individual key level. This new flag
Petko Manolov wrote:
> > > As far as i know there is no concept of write-once to a keyring in the
> > > kernel. David will correct me if i am wrong. I wonder how hard would
> > > it be to add such functionality, in case it is missing?
> >
> > Not hard, particularly if it's only an attribute th
On Wed, 2015-10-21 at 11:52 +0100, David Howells wrote:
> Petko Manolov wrote:
>
> > As far as i know there is no concept of write-once to a keyring in the
> > kernel. David will correct me if i am wrong. I wonder how hard would it be
> > to add such functionality, in case it is missing?
>
> N
On 15-10-21 07:22:58, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> > Mimi Zohar wrote:
> >
> > > Thinking about the blacklist keyring some more...
> >
> > Are we talking about a blacklist keyring that userspace can use - or can it
> > be only usable by the kerne
On 15-10-21 11:52:04, David Howells wrote:
> Petko Manolov wrote:
>
> > As far as i know there is no concept of write-once to a keyring in the
> > kernel. David will correct me if i am wrong. I wonder how hard would it
> > be
> > to add such functionality, in case it is missing?
>
> Not har
On Wed, 2015-10-21 at 11:55 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > > I need to think about this. Should -EKEYREVOKED be the same as -ENOKEY in
> > > this case? I guess the end result is pretty much the same from IMA view
> > > point, but there may be a requirement to list all rev
On 15-10-21 11:55:40, David Howells wrote:
> Mimi Zohar wrote:
>
> > > I need to think about this. Should -EKEYREVOKED be the same as -ENOKEY
> > > in
> > > this case? I guess the end result is pretty much the same from IMA view
> > > point, but there may be a requirement to list all revoked
On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > Thinking about the blacklist keyring some more...
>
> Are we talking about a blacklist keyring that userspace can use - or can it be
> only usable by the kernel?
The blacklist is referenced by the kernel before us
On 15-10-21 11:50:27, David Howells wrote:
> Mimi Zohar wrote:
>
> > Thinking about the blacklist keyring some more...
>
> Are we talking about a blacklist keyring that userspace can use - or can it
> be
> only usable by the kernel?
So far the discussion has been entirely in IMA context. Key
Mimi Zohar wrote:
> > I need to think about this. Should -EKEYREVOKED be the same as -ENOKEY in
> > this case? I guess the end result is pretty much the same from IMA view
> > point, but there may be a requirement to list all revoked keys...
>
> When checking the blacklist, getting -EKEYREVOKE
Petko Manolov wrote:
> As far as i know there is no concept of write-once to a keyring in the
> kernel. David will correct me if i am wrong. I wonder how hard would it be
> to add such functionality, in case it is missing?
Not hard, particularly if it's only an attribute that the kernel can se
Mimi Zohar wrote:
> Thinking about the blacklist keyring some more...
Are we talking about a blacklist keyring that userspace can use - or can it be
only usable by the kernel?
> My concern is more that keys can be added and removed at run time from
> either of the .ima or the ima_mok keyrings.
On Tue, 2015-10-20 at 21:42 +0300, Petko Manolov wrote:
> On 15-10-20 14:32:10, Mimi Zohar wrote:
> > On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> > >
> > > As far as i know there is no concept of write-once to a keyring in the
> > > kernel. David will correct me if i am wrong. I w
On 15-10-20 14:32:10, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> >
> > As far as i know there is no concept of write-once to a keyring in the
> > kernel. David will correct me if i am wrong. I wonder how hard would it
> > be
> > to add such functionality, in
On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> On 15-10-20 11:21:43, Mimi Zohar wrote:
> > On Tue, 2015-10-20 at 17:43 +0300, Petko Manolov wrote:
>
> > Thinking about the blacklist keyring some more... My concern is more that
> > keys can be added and removed at run time from either
On Tue, 2015-10-20 at 17:43 +0300, Petko Manolov wrote:
> Since having a proper CA hierarchy means access to both keyrings i never
> thought
> about separating them. The blacklist keyring should be functional without
> it's
> counterpart so yes, i think it should be possible to have option fo
On 15-10-20 11:21:43, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 17:43 +0300, Petko Manolov wrote:
>
> > Since having a proper CA hierarchy means access to both keyrings i never
> > thought about separating them. The blacklist keyring should be functional
> > without it's counterpart so yes, i t
On 15-10-20 10:13:34, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote:
> >
> > The code does not ties these keyrings around IMA. The way i've done it,
> > they are actually system wide keyrings and any other subsystem may use them.
> >
> > Since there was no general d
On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote:
> On 15-10-20 08:48:20, Mimi Zohar wrote:
> > On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote:
> > >
> > > This is all we've been using the blacklist keyring so far. By semantics
> > > it
> > > is system-wide keyring so maybe the co
On 15-10-20 08:48:20, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote:
> >
> > This is all we've been using the blacklist keyring so far. By semantics it
> > is system-wide keyring so maybe the commit message should be changed.
> > Nothing prevents others from using
On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote:
> On 15-10-19 14:20:48, Mimi Zohar wrote:
> > On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > > This option creates IMA MOK and blacklist keyrings. IMA MOK is an
> > > intermediate keyring that sits between .system and .ima keyrin
On 15-10-19 14:20:48, Mimi Zohar wrote:
> On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > This option creates IMA MOK and blacklist keyrings. IMA MOK is an
> > intermediate keyring that sits between .system and .ima keyrings,
> > effectively forming a simple CA hierarchy. To successfu
On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> This option creates IMA MOK and blacklist keyrings. IMA MOK is an
> intermediate keyring that sits between .system and .ima keyrings,
> effectively forming a simple CA hierarchy. To successfully import a key
> into .ima_mok it must be sign
This option creates IMA MOK and blacklist keyrings. IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy. To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that
26 matches
Mail list logo
