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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Dec 2012 09:55:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 0/2] ima: policy search speedup

On Tue, Dec 11, 2012 at 9:40 AM, Kasatkin, Dmitry
<dmitry.kasatkin@...el.com> 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?

> There are different filesystems which are not checked by IMA/EVM,
> such as pseudo-filesystems.

Did you read my email?

There are probably *also* individual that aren't checked by IMA/EVM
even on filesystems that *do* check other files.

No?

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() in
users. It's what the other security models already use to avoid
bothering calling down to the security layers. The fact that the
integrity layer bypasses the normal security layer in
ima_file_check(), for example, is no excuse to then make up totally
new flags.

So let me repeat: adding a new superblock flag seems STUPID. Why is it
in a completely different place than all the other flags that we
already have for these kinds of things? Why should we add a new field,
when we have existing fields that seem to do exactly this, do it
better, and are already used?

And don't ask me why without reading this email. OK?

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