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 11:10:04 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	Eric Paris <eparis@...isplace.org>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.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 10:59 AM, Mimi Zohar <zohar@...ux.vnet.ibm.com> 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
matter"?

For example, if you have cases where you know that a file has a
particular policy (or no policy what-so-ever) that never cares, then
for that file you can say "don't bother measuring this file" even
though in the generic case that may not be true.

Things like that might be the common case. Like "normal files owned by
uid > 500 are user files, and we simply don't care, and fall back to
just normal unix permissions".

And yes, things like that may end up requiring that the flag be
cleared on other inode events (ie changing file ownership of
executable flags or whatever, which might change a file from "don't
bother" to "hey, now it might be interesting again"). So maybe
chmod/chown/chgrp would clear that flag..

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, it's also the much more flexible place
to do it. Because it *allows* for things like that.

                  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/