Re: [PATCH 0/2] ima: policy search speedup

[Kasatkin, Dmitry]

On Tue, Dec 11, 2012 at 6:59 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Dec 11, 2012 at 6:08 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> 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.

What exactly seems stupid here?

>
> Without really knowing the problem space, the sane thing to do would
> seem to be inode->i_flags. At which point it's
>
>  (a) faster to test (no need to dereference inode->i_sb)
>
>  (b) matches what the integrity layer does with S_IMA (well, there the
> logic is reversed: S_IMA means that it has a integrity structure
> associated with it)
>
>  (c) allows you to mark individual inodes as "no checking".
>

There are inode specific objects which IMA uses for such perpose.

> and quite frankly, (c) in particular seems to make sense to me, since
> it would seem to be rather possible to do things like "I've checked
> this inode, it had no policies associated with it, I never need to
> check it again". Clear the flag when policies change or whatever.
>
> What's the advantage of making it per-filesystem?
>

There are different filesystems which are not checked by IMA/EVM,
such as pseudo-filesystems. For this reason it is good to have a way to
ignore such filesystems without to much work in IMA code.
No reason to check policy again and again for every inode on the filesystem
when the result will always be to ignore the filesystem.

Per-filesystem flag soles this problem.

- Dmitry


>             Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/