linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <CALLzPKZqw05_4V6NQeo-A6xOza2P4g6mqxDJnv7f-ktovj_HpQ@mail.gmail.com>
Date:	Tue, 18 Sep 2012 12:44:21 +0300
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-fsdevel@...r.kernel.org,
	linux-security-module <linux-security-module@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>
Subject: IMA policy search speedup

Hello Linus,

I have asked this question already 2 times in fsdevel but have not got
any single response.

Certain file system types and partitions will never be measured or
appraised depending on the IMA policy.
For example, pseudo file systems are not measured and appraised.
In upstream IMA implementation policy will be checked again and again
for every inode in the filesystem.
It happens thousands times per second. That is absolute waste of CPU
and may be batter resources.

To overcome such issue I would like to have a flag in super block data structure
which can be set once if IMA does not need to measure anything from a partition.
The flag might be tested by ima hooks to return without doing anything.

I looked to <linux/fs.h> and found that there is a possibility to to
add additional flag for sb->s_flags.
For example

#define MS_NOT_IMA              (1<<25) /* NOT_IMA */
#define IS_I_NOT_IMA(inode)   __IS_FLG(inode, MS_NOT_IMA)

Another way is to add additional dedicated integrity related member to
the sb structure.
struct super_block {
...
#ifdef CONFIG_INTEGRITY
      int s_integrity;
#endif
};

Obviously there are only few super blocks in the system and few bytes
will not harm.

Can you please advice about this?

Thanks,
Dmitry
--
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/