On Wed, Dec 12, 2012 at 8:56 AM, Kasatkin, Dmitry
wrote:
> I have done few tests.
> Ratio between lookups is different, but I do not really remember what
> exactly it was.
> Probably I did measurement with directory integrity protection...
>
> First test is done using upstream IMA.
>
> IMA-apprai
On Wed, Dec 12, 2012 at 1:02 AM, Eric Paris wrote:
> Linus made it clear he likes per-inode. Do a test with per-inode
> S_NOIMA. See how that compares to your 100,000 vs 10,000 lookups.
> Then we can discuss with facts if per sb is worth it or not. We still
> don't actually know if 100,000 look
Linus made it clear he likes per-inode. Do a test with per-inode
S_NOIMA. See how that compares to your 100,000 vs 10,000 lookups.
Then we can discuss with facts if per sb is worth it or not. We still
don't actually know if 100,000 lookups vs 10,000 lookups really
matters, but at least we'll hav
On Tue, Dec 11, 2012 at 10:08 PM, Eric Paris wrote:
> S_PRIVATE is totally unacceptable as it has a meaning across all LSMs,
> not just IMA.
>
> S_NOSEC means 'this is not setuid or setgid and we don't need to do
> those checks on modify'
>
> You are going to need to use a S_NOIMA.
>
> Of Dmitry's
On Tue, Dec 11, 2012 at 02:07:22PM -0500, Mimi Zohar wrote:
> On Tue, 2012-12-11 at 13:09 -0500, Eric Paris wrote:
> > On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds
> > wrote:
> >
> > > And your "pseudo-filesystems" argument is pretty stupid too, since WE
> > > ALREADY HAVE A FLAG FOR THAT!
>
On Tue, Dec 11, 2012 at 12:15 PM, Eric Paris wrote:
>
> I know it isn't relevant to the final solution, but this is simply
> wrong. IS_PRIVATE() means 'this inode is filesystem internal.' It is
> not used by anything except rieser and the anon_inode. If it is used
> by psuedo filesystems in gen
On Tue, Dec 11, 2012 at 3:05 PM, Linus Torvalds
wrote:
> The "IS_PRIVATE()" thing is more a "if you know a-priori that you
> aren't interested in pseudo-filesystems, you can already check that
> bit, because it will be set for things like /proc and shmem mappings
> and pipes etc".
I know it isn'
S_PRIVATE is totally unacceptable as it has a meaning across all LSMs,
not just IMA.
S_NOSEC means 'this is not setuid or setgid and we don't need to do
those checks on modify'
You are going to need to use a S_NOIMA.
Of Dmitry's 90,000 fewer policy lookups using the per sb flag, how
many of them
On Tue, Dec 11, 2012 at 11:48 AM, Mimi Zohar wrote:
>
> Ok. To summarize, S_IMA indicates that there is a rule and that the iint
> was allocated. To differentiate between 'haven't looked/don't know' and
> 'definitely not', we need another bit. For this, you're suggesting
> using IS_PRIVATE()? H
On Tue, 2012-12-11 at 11:10 -0800, Linus Torvalds wrote:
> Anyway, the whole "you can do it at file granularity" isn't the bulk
> of my argument (the "we already have the field that makes sense" is).
> But my point is that per-inode is not only the logically more
> straightforward place to do it,
On Tue, Dec 11, 2012 at 10:59 AM, Mimi Zohar wrote:
>
> Bottom line,
> we can't say definitively whether or not a file needs to be measured for
> any caller.
.. but is that actually *always* the case? Is there some fundamental
reason why integrity rules can never have "this file just doesn't
mat
On Tue, 2012-12-11 at 13:09 -0500, Eric Paris wrote:
> On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds
> wrote:
>
> > And your "pseudo-filesystems" argument is pretty stupid too, since WE
> > ALREADY HAVE A FLAG FOR THAT!
> >
> > Guess where it is? Oh, it's in the place I already mentioned makes
On Tue, 2012-12-11 at 13:35 -0500, Eric Paris wrote:
> On Tue, Dec 11, 2012 at 1:18 PM, Mimi Zohar wrote:
>
> > The appraisal policy is based on the object metadata, such as the uid,
> > so the result is static and can be cached. The measurement policy, on
> > the other hand, is normally based o
On Tue, Dec 11, 2012 at 8:35 PM, Linus Torvalds
wrote:
> On Tue, Dec 11, 2012 at 10:12 AM, Kasatkin, Dmitry
> wrote:
>>
>> Actually S_PRIVATE does not work work for normal filesystems which IMA
>> might want to ignore.
>
> The reading comprehension here is abysmal.
>
> First you claim that you ne
On Tue, Dec 11, 2012 at 10:12 AM, Kasatkin, Dmitry
wrote:
>
> Actually S_PRIVATE does not work work for normal filesystems which IMA
> might want to ignore.
The reading comprehension here is abysmal.
First you claim that you need the new flag for pseudo-filesystems, and
now that I point out that
On Tue, Dec 11, 2012 at 1:18 PM, Mimi Zohar wrote:
> The appraisal policy is based on the object metadata, such as the uid,
> so the result is static and can be cached. The measurement policy, on
> the other hand, is normally based on the subject (eg. who is
> reading/executing) the file. Knowl
On Tue, Dec 11, 2012 at 8:09 PM, Eric Paris wrote:
> On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds
> wrote:
>
>> And your "pseudo-filesystems" argument is pretty stupid too, since WE
>> ALREADY HAVE A FLAG FOR THAT!
>>
>> Guess where it is? Oh, it's in the place I already mentioned makes
>> mo
On Tue, Dec 11, 2012 at 08:10:07PM +0200, Kasatkin, Dmitry wrote:
> I was suggesting to add a flag for sb->s_flags field.
> Al said that he would not like this, because s_flags are mount specific.
s/mount-specific/in an incestous relationship with mount(2) ABI/.
--
To unsubscribe from this list:
On Tue, 2012-12-11 at 08:59 -0800, Linus Torvalds wrote:
> On Tue, Dec 11, 2012 at 6:08 AM, Mimi Zohar wrote:
> > On Tue, 2012-12-11 at 14:51 +0200, Kasatkin, Dmitry wrote:
> >> >>
> >> >> Two months ago I was asking about it on mailing lists.
> >> >> Suggestion was not to use s_flags, but e.g. s_
On Tue, Dec 11, 2012 at 7:55 PM, Linus Torvalds
wrote:
> On Tue, Dec 11, 2012 at 9:40 AM, Kasatkin, Dmitry
> wrote:
>>>
>>> Quite frankly, this seems stupid.
>>
>> What exactly seems stupid here?
>
> What I said. Go back and read it. I gave three reasons. Why do you ask?
>
> I'll give one more re
On Tue, Dec 11, 2012 at 7:55 PM, Linus Torvalds
wrote:
> On Tue, Dec 11, 2012 at 9:40 AM, Kasatkin, Dmitry
> wrote:
>>>
>>> Quite frankly, this seems stupid.
>>
>> What exactly seems stupid here?
>
> What I said. Go back and read it. I gave three reasons. Why do you ask?
>
> I'll give one more re
On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds
wrote:
> And your "pseudo-filesystems" argument is pretty stupid too, since WE
> ALREADY HAVE A FLAG FOR THAT!
>
> Guess where it is? Oh, it's in the place I already mentioned makes
> more sense. Look for S_PRIVATE in inode->i_flags, and IS_PRIVATE
On Tue, Dec 11, 2012 at 9:40 AM, Kasatkin, Dmitry
wrote:
>>
>> Quite frankly, this seems stupid.
>
> What exactly seems stupid here?
What I said. Go back and read it. I gave three reasons. Why do you ask?
I'll give one more reason, but you probably won't read *this* email
either, will you?
> Th
On Tue, Dec 11, 2012 at 6:59 PM, Linus Torvalds
wrote:
> On Tue, Dec 11, 2012 at 6:08 AM, Mimi Zohar wrote:
>> On Tue, 2012-12-11 at 14:51 +0200, Kasatkin, Dmitry wrote:
>>> >>
>>> >> Two months ago I was asking about it on mailing lists.
>>> >> Suggestion was not to use s_flags, but e.g. s_featu
On Tue, Dec 11, 2012 at 6:08 AM, Mimi Zohar wrote:
> On Tue, 2012-12-11 at 14:51 +0200, Kasatkin, Dmitry wrote:
>> >>
>> >> Two months ago I was asking about it on mailing lists.
>> >> Suggestion was not to use s_flags, but e.g. s_feature_flags.
Quite frankly, this seems stupid.
Without really k
On Tue, 2012-12-11 at 14:51 +0200, Kasatkin, Dmitry wrote:
> >> Here is two patches for policy search speedup.
> >>
> >> First patch adds additional features flags to superblock.
> >> Second - implementation for IMA.
> >>
> >> Two months ago I was asking about it on mailing lists.
> >> Suggestion
Hello Linus,
Can you please comment on the feature flag in this patchset?
Thanks,
Dmitry
On Tue, Nov 27, 2012 at 3:42 PM, Kasatkin, Dmitry
wrote:
> Hello,
>
> Any thoughts about this proposal?
>
> - Dmitry
>
> On Thu, Nov 22, 2012 at 11:54 PM, Dmitry Kasatkin
> wrote:
>> Hello,
>>
>> Here is
Hello,
Any thoughts about this proposal?
- Dmitry
On Thu, Nov 22, 2012 at 11:54 PM, Dmitry Kasatkin
wrote:
> Hello,
>
> Here is two patches for policy search speedup.
>
> First patch adds additional features flags to superblock.
> Second - implementation for IMA.
>
> Two months ago I was asking
28 matches
Mail list logo
