On Tue, Oct 27, 2015 at 10:01 AM, Mark D. Baushke wrote:
> Dmitry Kasatkin writes:
>
>> On Tue, Oct 27, 2015 at 12:36 AM, Mimi Zohar
>> wrote:
>> What I just ask is when we can get concurrent writers?
>>
>> I think system is updated by updating image or packages.
>
> Accretion of new packages a
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 mutex
> >
> > Ignore the high
Dmitry Kasatkin writes:
> On Tue, Oct 27, 2015 at 12:36 AM, Mimi Zohar wrote:
> What I just ask is when we can get concurrent writers?
>
> I think system is updated by updating image or packages.
Accretion of new packages and or updating those new packages is one
thing that a delegated tenant
On Tue, Oct 27, 2015 at 12:36 AM, 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 mutex
>>
>> Ignor
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 mutex
>
> Ignore the high level requirements for the moment. Every time yo
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 Sat, Oct 24, 2015 at 5:04 PM, Dmitry Kasatkin
wrote:
> On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov wrote:
>> 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 flexib
On Mon, 2015-10-26 at 16:01 +0200, Petko Manolov wrote:
> 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", d
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 Sat, 2015-10-24 at 17:04 +0300, Dmitry Kasatkin wrote:
> On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov wrote:
> > 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 f
On Sat, 2015-10-24 at 17:06 +0300, Dmitry Kasatkin wrote:
> Hi,
>
> 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 that the rules are scanned in FIFO
> > order so be car
Hi,
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 that the rules are scanned in FIFO
> order so be careful when you add new ones.
>
> The mutex locks are replaced with RCU,
On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov wrote:
> 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 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
> > fail. The user script or pro
On Fri, Oct 23, 2015 at 3:29 PM, Petko Manolov wrote:
> 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 ori
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 that the rules are scanned in FIFO
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 that the rules are scanned in FIFO
> order so be careful when you add new ones.
>
> The mutex
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
> > > index 816d175..a3cf5c0 100644
> > > --- a/s
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 when you add new ones.
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
> > index 816d175..a3cf5c0 100644
> > --- a/security/integrity/ima/ima_fs.c
> > +++ b/security/inte
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 when you add new ones.
>
> The mutex locks are replaced with RCU, whi
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 when you add new ones.
The mutex locks are replaced with RCU, which should lead to faster policy
traversals. The new rules are fir
23 matches
Mail list logo
