On Fri, Mar 08, 2013 at 10:09:48AM +0200, Kasatkin, Dmitry wrote:
[..]
> > - File could have invalid signature still iint->DIGSIG could be set and
> > security hook will return success.
> > - Assume system has booted with ima_appraise_tcb policy.
> > - A binary executes.
On Thu, Mar 7, 2013 at 11:56 PM, Vivek Goyal wrote:
> On Thu, Mar 07, 2013 at 07:53:50PM +0200, Kasatkin, Dmitry wrote:
>
> [..]
>
> Hi Dmitry,
>
>> Sorry if missed something from this lengthy thread and I repeat something.
>>
>> I have not noticed what functions you propose to export.
>
>
On Thu, Mar 7, 2013 at 11:56 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Mar 07, 2013 at 07:53:50PM +0200, Kasatkin, Dmitry wrote:
[..]
Hi Dmitry,
Sorry if missed something from this lengthy thread and I repeat something.
I have not noticed what functions you propose to export.
On Fri, Mar 08, 2013 at 10:09:48AM +0200, Kasatkin, Dmitry wrote:
[..]
- File could have invalid signature still iint-DIGSIG could be set and
security hook will return success.
- Assume system has booted with ima_appraise_tcb policy.
- A binary executes. bprm_check() is
On Thu, Mar 07, 2013 at 07:53:50PM +0200, Kasatkin, Dmitry wrote:
[..]
Hi Dmitry,
> Sorry if missed something from this lengthy thread and I repeat something.
>
> I have not noticed what functions you propose to export.
Actually I have not come up with functions yet. I have yet to write
the
On Thu, Mar 7, 2013 at 5:53 PM, Vivek Goyal wrote:
> On Thu, Mar 07, 2013 at 10:40:33AM -0500, Mimi Zohar wrote:
>> On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
>> > On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
>> > > On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:40:33AM -0500, Mimi Zohar wrote:
> On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
> > On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
> > > On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
> > > > On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi
On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
> On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
> > On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
> > > On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
>
> > Adding an IMA call to directly appraise the
On Thu, Mar 07, 2013 at 08:38:27AM -0500, Mimi Zohar wrote:
> On Wed, 2013-03-06 at 18:38 -0500, Vivek Goyal wrote:
> > On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
> > > On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
>
> [...]
> > > > - Because policy can be replaced
On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
> On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
> > On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
> >
> > [..]
> > > > Mimi, so you like this idea better than the other idea of keeping two
> > > > policy chains and
On Wed, 2013-03-06 at 18:38 -0500, Vivek Goyal wrote:
> On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
> > On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
[...]
> > > - Because policy can be replaced easily, some of the functionality
> > > will automatically be disabled.
On Wed, 2013-03-06 at 18:38 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
[...]
- Because policy can be replaced easily, some of the functionality
will automatically be disabled. (because
On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
[..]
Mimi, so you like this idea better than the other idea of keeping two
policy chains and running more
On Thu, Mar 07, 2013 at 08:38:27AM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 18:38 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
[...]
- Because policy can be replaced easily, some of
On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
Adding an IMA call to directly appraise the integrity of a
On Thu, Mar 07, 2013 at 10:40:33AM -0500, Mimi Zohar wrote:
On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
On Thu, Mar 7, 2013 at 5:53 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Mar 07, 2013 at 10:40:33AM -0500, Mimi Zohar wrote:
On Thu, 2013-03-07 at 09:36 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 08:39:08PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal
On Thu, Mar 07, 2013 at 07:53:50PM +0200, Kasatkin, Dmitry wrote:
[..]
Hi Dmitry,
Sorry if missed something from this lengthy thread and I repeat something.
I have not noticed what functions you propose to export.
Actually I have not come up with functions yet. I have yet to write
the
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
> On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
>
> [..]
> > > Mimi, so you like this idea better than the other idea of keeping two
> > > policy chains and running more restrictive rule while resolving flag
> > > conflicts
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
[..]
> > Mimi, so you like this idea better than the other idea of keeping two
> > policy chains and running more restrictive rule while resolving flag
> > conflicts between two rules?
> >
> > I have written some patches to maintain
On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
> On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
> > On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
> >
> > [..]
> > > > The fact that we are able to replace ima_mem_exec policy using command
> > > > line, binary
On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
> On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
>
> [..]
> > > The fact that we are able to replace ima_mem_exec policy using command
> > > line, binary loader will need a way to query IMA to find what's the
> > > current policy.
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
[..]
> > The fact that we are able to replace ima_mem_exec policy using command
> > line, binary loader will need a way to query IMA to find what's the
> > current policy. If ima_mem_exec has been replaced, then binary loader
> > will
On Tue, 2013-03-05 at 16:53 -0500, Vivek Goyal wrote:
> On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
> > On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
> >
> > > Can we do following. (Just modifying your proposal little bit).
> > >
> > > - Implement a new policy say
On Tue, 2013-03-05 at 16:53 -0500, Vivek Goyal wrote:
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
Can we do following. (Just modifying your proposal little bit).
- Implement a new policy say ima_mem_exec. This
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
[..]
The fact that we are able to replace ima_mem_exec policy using command
line, binary loader will need a way to query IMA to find what's the
current policy. If ima_mem_exec has been replaced, then binary loader
will not
On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
[..]
The fact that we are able to replace ima_mem_exec policy using command
line, binary loader will need a way to query IMA to find what's the
current policy. If
On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
[..]
The fact that we are able to replace ima_mem_exec policy using command
line, binary loader will need a
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
[..]
Mimi, so you like this idea better than the other idea of keeping two
policy chains and running more restrictive rule while resolving flag
conflicts between two rules?
I have written some patches to maintain two rule
On Wed, 2013-03-06 at 18:55 -0500, Vivek Goyal wrote:
On Wed, Mar 06, 2013 at 10:42:31AM -0500, Mimi Zohar wrote:
[..]
Mimi, so you like this idea better than the other idea of keeping two
policy chains and running more restrictive rule while resolving flag
conflicts between two
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
> On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
>
> > Can we do following. (Just modifying your proposal little bit).
> >
> > - Implement a new policy say ima_mem_exec. This policy can vary based on
> > config options. This
On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
> Can we do following. (Just modifying your proposal little bit).
>
> - Implement a new policy say ima_mem_exec. This policy can vary based on
> config options. This will be the default policy.
Just to clarify, the default is the existing
On Mon, Mar 04, 2013 at 08:21:31PM -0500, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 14:15 -0500, Vivek Goyal wrote:
>
> > I am just brain storming and throwing some ideas and see if soemthing
> > makes sense. I agree that allowing one policy only makes it very
> > restrictive (while simplifying
On Mon, Mar 04, 2013 at 08:21:31PM -0500, Mimi Zohar wrote:
On Mon, 2013-03-04 at 14:15 -0500, Vivek Goyal wrote:
I am just brain storming and throwing some ideas and see if soemthing
makes sense. I agree that allowing one policy only makes it very
restrictive (while simplifying the
On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
Can we do following. (Just modifying your proposal little bit).
- Implement a new policy say ima_mem_exec. This policy can vary based on
config options. This will be the default policy.
Just to clarify, the default is the existing
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
Can we do following. (Just modifying your proposal little bit).
- Implement a new policy say ima_mem_exec. This policy can vary based on
config options. This will be the
On Mon, 2013-03-04 at 14:15 -0500, Vivek Goyal wrote:
> I am just brain storming and throwing some ideas and see if soemthing
> makes sense. I agree that allowing one policy only makes it very
> restrictive (while simplifying the implementation).
Agreed, lets try again ... I think we are
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
> I was thinking more in terms of merging flags. Merging the flags in
> your example would work.
>
> appraise func=bprm_check appraise_type=optional cache_status=no
> appraise fowner=root
> example 2: merging the flags results in
On Mon, Mar 04, 2013 at 01:59:41PM -0500, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
> [...]
>
> > Hi Mimi,
> >
> > If we decide to merge flags, then practically we modified the
> > ima_appraise_tcb policy. ima_appraise_tcb policy expects to cache the
> > results
I think that is what he was suggesting. It reuses the integrity code
but it loses the integrity flexibility. I don't think it is a good
solution :-(
On Mon, Mar 4, 2013 at 1:59 PM, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
> [...]
>
>> Hi Mimi,
>>
>> If we
On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
[...]
> Hi Mimi,
>
> If we decide to merge flags, then practically we modified the
> ima_appraise_tcb policy. ima_appraise_tcb policy expects to cache the
> results and we will not do that. And this conflict just grows if we
> are forced to
On Mon, Mar 04, 2013 at 10:29:19AM -0500, Vivek Goyal wrote:
[..]
> This reduces our options but trying to make multiple policies co-exist
> together is just making it complicated. We can take it up again when
> somebody has a strong use case of using secureboot policy along with
> other
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
> > > We've already spoken about needing an additional hook or moving the
> > > existing bprm hook. Can we defer the memory caching requirements for
> > > now?
> >
> > Sure, additional hook is not a concern.
> >
> > I can defer
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
We've already spoken about needing an additional hook or moving the
existing bprm hook. Can we defer the memory caching requirements for
now?
Sure, additional hook is not a concern.
I can defer caching discussion
On Mon, Mar 04, 2013 at 10:29:19AM -0500, Vivek Goyal wrote:
[..]
This reduces our options but trying to make multiple policies co-exist
together is just making it complicated. We can take it up again when
somebody has a strong use case of using secureboot policy along with
other policies.
On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
[...]
Hi Mimi,
If we decide to merge flags, then practically we modified the
ima_appraise_tcb policy. ima_appraise_tcb policy expects to cache the
results and we will not do that. And this conflict just grows if we
are forced to add
I think that is what he was suggesting. It reuses the integrity code
but it loses the integrity flexibility. I don't think it is a good
solution :-(
On Mon, Mar 4, 2013 at 1:59 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
[...]
Hi
On Mon, Mar 04, 2013 at 01:59:41PM -0500, Mimi Zohar wrote:
On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
[...]
Hi Mimi,
If we decide to merge flags, then practically we modified the
ima_appraise_tcb policy. ima_appraise_tcb policy expects to cache the
results and we will
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
I was thinking more in terms of merging flags. Merging the flags in
your example would work.
appraise func=bprm_check appraise_type=optional cache_status=no
appraise fowner=root
example 2: merging the flags results in the
On Mon, 2013-03-04 at 14:15 -0500, Vivek Goyal wrote:
I am just brain storming and throwing some ideas and see if soemthing
makes sense. I agree that allowing one policy only makes it very
restrictive (while simplifying the implementation).
Agreed, lets try again ... I think we are actually
On Fri, 2013-03-01 at 16:33 -0500, Vivek Goyal wrote:
> On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
>
> [..]
> > I was suggesting that a builtin appraise rule chain and everything else
> > on the other chain. Userspace could replace the other chain with
> > whatever they wanted,
On Fri, 2013-03-01 at 16:33 -0500, Vivek Goyal wrote:
On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
[..]
I was suggesting that a builtin appraise rule chain and everything else
on the other chain. Userspace could replace the other chain with
whatever they wanted, including
On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
[..]
> I was suggesting that a builtin appraise rule chain and everything else
> on the other chain. Userspace could replace the other chain with
> whatever they wanted, including additional appraisal rules.
>
> > > Given the fact that
On Fri, 2013-03-01 at 13:40 -0500, Vivek Goyal wrote:
> On Fri, Mar 01, 2013 at 10:28:40AM -0500, Vivek Goyal wrote:
> > On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
> > > On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> > > > On Thu, 2013-02-28 at 17:20 -0500, Eric Paris
On Fri, Mar 01, 2013 at 10:28:40AM -0500, Vivek Goyal wrote:
> On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
> > On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> > > On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
> >
> > > > The ima_tcb policy was meant to be larger than
On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> > On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
>
> > > The ima_tcb policy was meant to be larger than needed to determine a
> > > trusted computing base, but it is clearly
On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
> > The ima_tcb policy was meant to be larger than needed to determine a
> > trusted computing base, but it is clearly not a superset of what he is
> > hoping to accomplish.
The builtin
On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
The ima_tcb policy was meant to be larger than needed to determine a
trusted computing base, but it is clearly not a superset of what he is
hoping to accomplish.
The builtin
On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
The ima_tcb policy was meant to be larger than needed to determine a
trusted computing base, but it is clearly not a
On Fri, Mar 01, 2013 at 10:28:40AM -0500, Vivek Goyal wrote:
On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
The ima_tcb policy was meant to be larger than needed to
On Fri, 2013-03-01 at 13:40 -0500, Vivek Goyal wrote:
On Fri, Mar 01, 2013 at 10:28:40AM -0500, Vivek Goyal wrote:
On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
[..]
I was suggesting that a builtin appraise rule chain and everything else
on the other chain. Userspace could replace the other chain with
whatever they wanted, including additional appraisal rules.
Given the fact that policy
On Thu, 2013-02-28 at 16:35 -0500, Vivek Goyal wrote:
> On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
>
> [..]
> > I would suggest that the ima_appraise_tcb, which is more restrictive, be
> > permitted to replace the secureboot policy.
>
> Also ima_appraise_tcb is not necessarily
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
> On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal wrote:
> > On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
>
> I think just a second for both of you to step back and see a slightly
> larger picture/problem might help.
>
> This is a
On Thu, 2013-02-28 at 15:08 -0500, Vivek Goyal wrote:
> - New hook is required so that we can call it after locking down the
> executable in memory. Even if we have a separate method/hook for
> bzImage verification, it does not take away the need for verifying
> /sbin/kexec excutable
On Thu, 2013-02-28 at 15:57 -0500, Vivek Goyal wrote:
> Hi Mimi,
>
> You asked me to not come up with new signing scheme and look into IMA
> and make use of it. And that's what I am trying to do. As I continue
> to do implementation, new concerns crop up and I am raising these.
And I appreciate
On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal wrote:
> On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
I think just a second for both of you to step back and see a slightly
larger picture/problem might help.
This is a weird case where Vivek does not trust root to make the
policy
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
[..]
> I would suggest that the ima_appraise_tcb, which is more restrictive, be
> permitted to replace the secureboot policy.
Also ima_appraise_tcb is not necessarily more restrictive. It takes
appraises only for root user. Files for
On Thu, Feb 28, 2013 at 03:30:01PM -0500, Mimi Zohar wrote:
[..]
> > So we need few more things from IMA for it to support the case of user
> > space signing.
> >
> > - Ability to make sure kernel specified rules can not be overridden.
>
> Our posts must have crossed -
>
On Thu, 2013-02-28 at 13:51 -0500, Vivek Goyal wrote:
> On Thu, Feb 28, 2013 at 10:13:33AM -0500, Vivek Goyal wrote:
> > Hi Mimi,
> >
> > I am running into issues w.r.t IMA policy management and user space
> > signing. So thought of dropping a mail and gather some ideas.
> >
> > Currently IMA
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote:
> > Hi Mimi,
> >
> > I am running into issues w.r.t IMA policy management and user space
> > signing. So thought of dropping a mail and gather some ideas.
> >
> > Currently IMA
On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote:
> Hi Mimi,
>
> I am running into issues w.r.t IMA policy management and user space
> signing. So thought of dropping a mail and gather some ideas.
>
> Currently IMA seems to able to one policy only which does not contain
> conflicting rules.
On Thu, Feb 28, 2013 at 10:13:33AM -0500, Vivek Goyal wrote:
> Hi Mimi,
>
> I am running into issues w.r.t IMA policy management and user space
> signing. So thought of dropping a mail and gather some ideas.
>
> Currently IMA seems to able to one policy only which does not contain
> conflicting
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to one policy only which does not contain
conflicting rules. We have tcb policies in-built and they don't have
conflicting rules.
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to one policy only which does not contain
conflicting rules. We have tcb policies in-built and they don't have
conflicting rules.
On Thu, Feb 28, 2013 at 10:13:33AM -0500, Vivek Goyal wrote:
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to one policy only which does not contain
conflicting rules.
On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote:
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to one policy only which does not contain
conflicting rules. We have
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote:
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to
On Thu, 2013-02-28 at 13:51 -0500, Vivek Goyal wrote:
On Thu, Feb 28, 2013 at 10:13:33AM -0500, Vivek Goyal wrote:
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able
On Thu, Feb 28, 2013 at 03:30:01PM -0500, Mimi Zohar wrote:
[..]
So we need few more things from IMA for it to support the case of user
space signing.
- Ability to make sure kernel specified rules can not be overridden.
Our posts must have crossed -
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
[..]
I would suggest that the ima_appraise_tcb, which is more restrictive, be
permitted to replace the secureboot policy.
Also ima_appraise_tcb is not necessarily more restrictive. It takes
appraises only for root user. Files for rest
On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
I think just a second for both of you to step back and see a slightly
larger picture/problem might help.
This is a weird case where Vivek does not trust root to make
On Thu, 2013-02-28 at 15:57 -0500, Vivek Goyal wrote:
Hi Mimi,
You asked me to not come up with new signing scheme and look into IMA
and make use of it. And that's what I am trying to do. As I continue
to do implementation, new concerns crop up and I am raising these.
And I appreciate it.
On Thu, 2013-02-28 at 15:08 -0500, Vivek Goyal wrote:
- New hook is required so that we can call it after locking down the
executable in memory. Even if we have a separate method/hook for
bzImage verification, it does not take away the need for verifying
/sbin/kexec excutable signature.
On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
I think just a second for both of you to step back and see a slightly
larger picture/problem might help.
On Thu, 2013-02-28 at 16:35 -0500, Vivek Goyal wrote:
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
[..]
I would suggest that the ima_appraise_tcb, which is more restrictive, be
permitted to replace the secureboot policy.
Also ima_appraise_tcb is not necessarily more
86 matches
Mail list logo
