Date:	Mon, 25 Oct 2010 12:38:35 -0700
From:	"J.H." <warthog9@...nel.org>
To:	John Stoffel <john@...ffel.org>
CC:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, hch@...radead.org, zohar@...ibm.com,
	david@...morbit.com, jmorris@...ei.org, kyle@...artin.ca,
	hpa@...or.com, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, mingo@...e.hu,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode
 information cache

On 10/25/2010 12:21 PM, John Stoffel wrote:
>>>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:
> 
> Eric> The IMA code needs to store the number of tasks which have an
> Eric> open fd granting permission to write a file even when IMA is not
> Eric> in use.  It needs this information in order to be enabled at a
> Eric> later point in time without losing it's integrity garantees.
> 
> This sounds completely wrong to me.  If I disable IMA (but have the
> sucker compiled in due to a vendor...) I don't want *any* overhead,
> and this is speaking using my SysAdmin hat for people who do EDA
> design work, and having fast systems is key for us.  IMA is NOT.  We
> disable SELINUX too, because of the overhead and the maintenance
> nightmare.

I'll second both points.  If IMA is disabled, but compiled in, it *HAS*
to consume 0 resources.  It's defective by design if something that is
only useful to 1% of the userbase (guesstimating) consumes even 1% of
the resources on any and all machines that are deployed with it.  It's
just plain wasteful of power, cooling, ram, compute resources, etc.

Keep in mind distros are going to err on the side of compiling things in
(either into the kernel or as modules) because there is a customer
*SOMEWHERE* that wants it.  Penalizing the rest of us, and forcing us
(effectively) to buy more ram, is not a good option.

> If IMA isn't enabled right from the get-go, how can you ensure
> integrity?  And how can you ensure integrity if root is compromised?
> If root can disable IMA, screw around with a file, then turn on IMA
> again without the change being guarrentteed to be noticed (and not
> because the attacked didn't do the attack perfectly!) what's the use?
> 
> How does this help any?  
> 
> To quote from:
> http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html
> 
>     What IMA is not
> 
>     IMA is not controlling your system. IMA is non-intrusive and is best
>     described as an independent observer collecting integrity information
>     of loaded code or sensitive application files on demand. Consequently,
>     IMA does not prevent a system from illegal behavior that might
>     compromise the system including the integrity measurement architecture
>     itself. Recognizing the danger of being by-passed, IMA simply
>     invalidates its own measurement list by invalidating the TPM integrity
>     aggregate and thereby rendering the evidence useless (non-verifiable)
>     until it is reset during the next system reboot. For example, if
>     applications write directly to a device (/dev/hda, /dev/sda) or kernel
>     memory (/dev/kmem), then IMA invalidates the TPM aggregate.
> 
>     IMA is not a Digital Rights Management tool either. IMA collects
>     evidence on the local system, which can be used for many purposes but
>     whose release is fully controlled by the local system. It is getting
>     harder to lie about what you are running when you use IMA; no doubt
>     about it. However, if system security is going to be reality, systems
>     that lie at will seem not a convincing alternative in a distributed
>     environment where the weakest link determines the security of the
>     distributed service. The price to pay is that properties must be
>     established securely and that the balance between use and abuse of
>     knowledge about such properties as well as the validity of requiring
>     such evidence (e.g., before connecting a system to a video-on-demand
>     service) must be controlled by rules that are enforced the same way
>     they are in other areas of our daily life (most likely by laws).
> 
> 
> So basically, IMA is super duper tripwire with the ability to allow
> some remote system to come in and ask for your Hashes.  And if you
> screw around with it, it immediately disables itself.  
> 
> Which seems to fly in the face of your claim that it needs to be able
> to re-enable itself by tracking open inodes even when disabled.

Wouldn't an enterprising root-kit snag root, muck with IMA and then muck
with other files?  I mean I'm happy that it will trip-wire the
incompetent or old root kits, but if root can enable/disable this
outside of boot it's completely pointless.

> 
> Eric>   At the moment that means we store a little bit of data about
> Eric> every inode in a cache.  We use a radix tree key'd on the
> Eric> inode's memory address.  Dave Chinner pointed out that a radix
> Eric> tree is a terrible data structure for such a sparse key space.
> Eric> This patch switches to using an rbtree which should be more
> Eric> efficient.
> 
> As the number of inodes goes up (say during a backup which reads
> them...) won't the size of this cache go up as well, even when IMA is
> disabled?  Why is this overhead even needed?  

Ignore backups, file servers and large webservers (read: basically
kernel.org's *ENTIRE* infrastructure) basically trips over this case.
To throw fire on the whole thing, if there are 100 mirrors in a
mirroring infrastructure (not uncommon for some distros) and they all
have IMA disabled but compiled in, and they are all rsyncing data (say a
distro release is ongoing) you are talking about a huge amount of waste
across all those machines.

I'd argue disabled = takes up no resources, that's what a sysadmin is
going to generally expect particularly for something that not many of
them are going to want to take advantage of.

Just my $0.02usd anyway.

- John 'Warthog9' Hawley
--
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/

Powered by blists - more mailing lists