On 16-01-06 13:21:27, David Howells wrote:
> Mimi Zohar wrote:
>
> > The x509_validate_trust() was originally added for IMA to ensure, on a
> > secure boot system, a certificate chain of trust rooted in hardware. The
> > IMA
> > MOK keyring extends this certificate chain of trust to the runnin
On 16-01-05 16:40:31, David Howells wrote:
> Mimi Zohar wrote:
>
> > You're missing Petko's patch:
> > 41c89b6 IMA: create machine owner and blacklist keyrings
>
> It should also be cc'd to the keyrings mailing list.
Right.
If i am not terribly mistaken there's no way to revoke a certificate t
On 15-12-28 09:42:22, Mimi Zohar wrote:
> On Mon, 2015-12-28 at 16:29 +0200, Petko Manolov wrote:
> >
> > I kind of wonder isn't it possible to optimize the file read? If the file
> > is relatively small (a few megabytes, for example) it will fit into any
> > m
On 15-12-28 07:51:15, Mimi Zohar wrote:
> On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote:
> > On 12/25/15 at 09:45am, Mimi Zohar wrote:
> > > IMA calculates the file hash, in this case, based on the buffer
> > > contents. The hash is calculated once and used for both measurement
> > > and ap
On 15-12-22 16:50:01, Sasha Levin wrote:
> On 12/22/2015 04:40 PM, Petko Manolov wrote:
> >> Thanks, Sasha. By the time ima_update_policy() is called
> >> >ima_release_policy() has already output the policy update status
> >> >message. I guess an empty polic
On December 22, 2015 9:56:28 PM GMT+02:00, Mimi Zohar
wrote:
>On Tue, 2015-12-22 at 08:51 -0500, Sasha Levin wrote:
>> Commit "IMA: policy can now be updated multiple times" assumed that
>the
>> policy would be updated at least once.
>>
>> If there are zero updates, the temporary list head objec
On 15-12-08 13:01:24, Mimi Zohar wrote:
> Require the IMA policy to be signed when additional rules can be added.
>
> Signed-off-by: Mimi Zohar
> ---
> security/integrity/ima/ima_policy.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/security/integrity/ima/ima_policy.c
> b/secur
On 15-12-08 13:01:18, Mimi Zohar wrote:
> While creating a temporary list of new rules, the ima_appraise flag is
> updated, but not reverted on failure to append the new rules to the
> existing policy. This patch defines temp_ima_appraise flag. Only when
> the new rules are appended to the policy
It is often useful to be able to read back the IMA policy. It is
even more important after introducing CONFIG_IMA_WRITE_POLICY.
This option allows the root user to see the current policy rules.
Signed-off-by: Zbigniew Jasinski
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig
returned to the caller.
Signed-off-by: Petko Manolov
---
crypto/asymmetric_keys/x509_public_key.c | 2 ++
include/keys/system_keyring.h| 24 ++
security/integrity/digsig_asymmetric.c | 14 +
security/integrity/ima/Kconfig | 18 +++
security
orders of magnitude more numerous compared to
writes, the match code is RCU protected. The updater side also does
list splice in RCU manner.
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig | 11 ++
security/integrity/ima/ima_fs.c | 13 ++
security/integrity/ima
user to see the current
policy rules.
Petko Manolov (3):
IMA policy can now be updated multiple times.
Create IMA machine owner and blacklist keyrings;
Allows reading back the current IMA policy.
crypto/asymmetric_keys/x509_public_key.c | 2 +
include/keys/system_keyring.h|
On December 1, 2015 11:03:32 PM GMT+02:00, David Howells
wrote:
>Petko Manolov wrote:
>
>> 0) does keyrings keep a timestamp when created or last updated?
>David?
>
>No.
>
>> 0) is crucial. If there is no such thing as "time of the last
>update"
On 15-12-01 13:40:05, Mimi Zohar wrote:
> On Tue, 2015-12-01 at 18:51 +0200, Petko Manolov wrote:
> >
> > I'll also send you something resembling a patch about iint invalidation
> > based on
> > .ima_blacklist updates. I've got a few questions.
>
>
On 15-11-09 09:30:58, Mimi Zohar wrote:
> On Mon, 2015-11-02 at 00:39 +0200, Petko Manolov wrote:
>
> > +
> > +#ifdef CONFIG_IMA_READ_POLICY
> > +enum {
> > + mask_err = -1,
> > + mask_exec = 1, mask_write, mask_read, mask_append
> > +};
&
When developing or debugging an IMA enabled system it is useful to be
able to read back the current policy. This code provides that
functionality.
Signed-off-by: Zbigniew Jasinski
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig | 11 ++
security/integrity/ima/ima.h
returned to the caller.
Signed-off-by: Petko Manolov
---
crypto/asymmetric_keys/x509_public_key.c | 2 ++
include/keys/system_keyring.h| 24 ++
security/integrity/digsig_asymmetric.c | 14 +
security/integrity/ima/Kconfig | 18 +++
security
orders of magnitude more numerous compared to
writes, the match code is RCU protected. The updater side also does
list splice in RCU manner.
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig | 11 +
security/integrity/ima/ima_fs.c | 13 ++
security/integrity/ima
insecure and is strongly discouraged
for production-grade kernels.
Petko Manolov (3):
IMA policy can now be updated multiple times.
Create IMA machine owner and blacklist keyrings;
Allows reading back the current IMA policy;
crypto/asymmetric_keys/x509_public_key.c | 2 +
include/keys
On 15-10-27 09:37:56, Dmitry Kasatkin wrote:
>
> What I just ask is when we can get concurrent writers?
Yes. I think Mark Baushke just did that.
> I think system is updated by updating image or packages.
Nope, ours isn't using the conventional mechanism of "packages".
> In the first case poli
On 15-10-26 18:36:33, Mimi Zohar wrote:
> On Tue, 2015-10-27 at 00:03 +0200, Petko Manolov wrote:
> > On 15-10-26 22:39:28, Dmitry Kasatkin wrote:
>
> > > Can you please still explain when multiple policy writers can content? I
> > > 100% understand the role of mute
On 15-10-26 22:39:28, Dmitry Kasatkin wrote:
>
> We had some discussion with Mimi and could not come to conclusion..
No problems there: truth springs from argument amongst friends.
> Can you please still explain when multiple policy writers can content? I 100%
> understand the role of mutex
On 15-10-25 07:50:32, Mimi Zohar wrote:
> On Sat, 2015-10-24 at 17:06 +0300, Dmitry Kasatkin wrote:
>
> > > @@ -171,9 +172,8 @@ static int __init default_appraise_policy_setup(char
> > > *str)
> > > __setup("ima_appraise_tcb", default_appraise_policy_setup);
> > >
> > > /*
> > > - * Although th
On 15-10-23 20:13:41, Dmitry Kasatkin wrote:
> On Fri, Oct 23, 2015 at 3:29 PM, Petko Manolov wrote:
> >
> > I was actually going to get rid of IMA_FS_BUSY. It is less flexible with
> > respect to user-space tools. If the flag is up then the policy upload will
> >
On 15-10-23 14:43:53, Mimi Zohar wrote:
> On Fri, 2015-10-23 at 16:05 +0300, Petko Manolov wrote:
> > On 15-10-22 21:49:25, Dmitry Kasatkin wrote:
>
> > > diff --git a/security/integrity/ima/Kconfig
> > > b/security/integrity/ima/Kconfig
> > > index df303
On 15-10-22 21:49:25, Dmitry Kasatkin wrote:
> Require all keys added to the EVM keyring be signed by an
> existing trusted key on the system trusted keyring.
>
> This patch also switches IMA to use integrity_init_keyring().
>
> Changes in v3:
> * Added 'init_keyring' config based variable to ski
On 15-10-22 22:15:30, Dmitry Kasatkin wrote:
> Hi Petko,
>
> I have a question
>
> On Fri, Oct 16, 2015 at 10:31 PM, Petko Manolov wrote:
> > IMA policy can now be updated multiple times. The new rules get appended
> > to the original policy. Have in mind th
On 15-10-21 13:02:48, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> > Here's a set of patches that changes how keys are determined to be trusted
> > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> > it. A keyring can then have a flag set
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 sema
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
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, i
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 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
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
&g
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
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.
> >
On 15-10-20 09:03:19, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 15:10 +0300, Petko Manolov wrote:
> >
> > By "security hole" i mean being able to read it at all. Root or non-root.
> > Knowing what the IMA policy is may give the attacker an idea how to
> >
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.
> > No
On 15-10-20 08:00:29, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 10:26 +0300, Petko Manolov wrote:
> > On 15-10-19 14:21:42, Mimi Zohar wrote:
> > > On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > > > When in development it is useful to read back the IM
On 15-10-16 22:31:31, Petko Manolov wrote:
> When in development it is useful to read back the IMA policy. This patch
> provides the functionality. However, this is a potential security hole so
> it should not be used in production-grade kernels.
>
> Signed-off-by
On 15-10-19 18:28:22, Mimi Zohar wrote:
> On Mon, 2015-10-19 at 14:21 -0400, Mimi Zohar wrote:
> > On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
>
> > > diff --git a/security/integrity/ima/ima_fs.c
> > > b/security/integrity/ima/ima_fs.c
> > > in
On 15-10-19 14:21:03, Mimi Zohar wrote:
> On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > IMA policy can now be updated multiple times. The new rules get appended
> > to the original policy. Have in mind that the rules are scanned in FIFO
> > order so be careful
On 15-10-19 14:21:42, Mimi Zohar wrote:
> On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > When in development it is useful to read back the IMA policy. This patch
> > provides the functionality. However, this is a potential security hole so
> > it should not
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 sim
system it is often useful to be
able to read the IMA policy. This patch allows for doing so. However, being
able to read the IMA policy is considered insecure and is strongly discouraged
for production-grade kernels.
Petko Manolov (3):
Enable multiple writes to the IMA policy;
Create IMA
first appended to a temporary list, which
on error gets released without disturbing the normal IMA operations.
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig | 14
security/integrity/ima/ima_fs.c | 13 +++
security/integrity/ima/ima_policy.c | 70
returned to the caller.
Signed-off-by: Petko Manolov
---
crypto/asymmetric_keys/x509_public_key.c | 2 ++
include/keys/system_keyring.h| 24 ++
security/integrity/digsig_asymmetric.c | 14 +
security/integrity/ima/Kconfig | 17 ++
security
When in development it is useful to read back the IMA policy. This patch
provides the functionality. However, this is a potential security hole so
it should not be used in production-grade kernels.
Signed-off-by: Petko Manolov
---
security/integrity/ima/Kconfig | 13 +++
security
__list_splice_init_rcu() can be used to splice lists forming both stack and
queue structures, depending on its arguments. It is based on the initial
list_splice_init_rcu() with a few minor modifications to help abstrancting it.
Signed-off-by: Petko Manolov
---
include/linux/rculist.h | 69
On 15-10-02 13:15:49, Mimi Zohar wrote:
> On Thu, 2015-09-10 at 14:17 +0300, Petko Manolov wrote:
> > The .system keyring is populated at kernel build time and read-only while
> > the
> > system is running. There is no way to dynamically add other user's CA so
> >
On 15-10-06 11:37:01, Paul E. McKenney wrote:
> On Sun, Sep 27, 2015 at 06:10:28PM +0300, Petko Manolov wrote:
> > __list_splice_init_rcu() can be used to splice lists forming both stack and
> > queue structures, depending on its arguments. It is based on the initial
> >
52 matches
Mail list logo
