linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, hch@infradead.org,
	zohar@us.ibm.com, warthog9@kernel.org, david@fromorbit.com,
	jmorris@namei.org, kyle@mcmartin.ca, hpa@zytor.com,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	mingo@elte.hu, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 06/11] IMA: use i_writecount rather than a private counter
Date: Mon, 25 Oct 2010 15:27:19 -0400	[thread overview]
Message-ID: <19653.55831.692904.538148@quad.stoffel.home> (raw)
In-Reply-To: <20101025184152.20504.94048.stgit@paris.rdu.redhat.com>

>>>>> "Eric" == Eric Paris <eparis@redhat.com> writes:

Eric> IMA tracks the number of struct files which are holding a given
Eric> inode readonly and the number which are holding the inode write
Eric> or r/w.  It needs this information so when a new reader or
Eric> writer comes in it can tell if this new file will be able to
Eric> invalidate results it already made about existing files.

Eric> aka if a task is holding a struct file open RO, IMA measured the
Eric> file and recorded those measurements and then a task opens the
Eric> file RW IMA needs to note in the logs that the old measurement
Eric> may not be correct.  It's called a "Time of Measure Time of Use"
Eric> (ToMToU) issue.  The same is true is a RO file is opened to an
Eric> inode which has an open writer.  We cannot, with any validity,
Eric> measure the file in question since it could be changing.

So if ToMToU is blown away by opening a file RW, how do you handle a
denial of attack which just opens and closes a bunch of files under
IMA control as fast as it can?  

What happens then?  Does IMA try to re-calculate it's integrity
measurement each and every time this happens?  What does this do to
system performance?  

If I open a file RO, read 512 bytes in a random block, then writes
those same 512 bytes back to the exact same spot, what happens?  

While I'm really concerned about the overhead when it's disabled, I'm
not sure you've explained the overhead when it *IS* enabled, esp on
systems with lots of disks and lots of files.  

The problems with kernel.org is a perfect exmaple of how an annocuous
feature like this, can kill a system's performance.

John


Eric> This patch attempts to use the i_writecount field to track writers.  The
Eric> i_writecount field actually embeds more information in it's value than IMA
Eric> needs but it should work for our purposes and allow us to shrink the struct
Eric> inode even more.

Eric> Signed-off-by: Eric Paris <eparis@redhat.com>
Eric> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Eric> ---

Eric>  security/integrity/ima/ima.h      |    1 -
Eric>  security/integrity/ima/ima_iint.c |    6 ------
Eric>  security/integrity/ima/ima_main.c |   16 ++++++----------
Eric>  3 files changed, 6 insertions(+), 17 deletions(-)

Eric> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
Eric> index 80aca3d..b546b90 100644
Eric> --- a/security/integrity/ima/ima.h
Eric> +++ b/security/integrity/ima/ima.h
Eric> @@ -108,7 +108,6 @@ struct ima_iint_cache {
Eric>  	struct mutex mutex;	/* protects: version, flags, digest */
Eric>  	/* protected by inode->i_lock */
Eric>  	unsigned int readcount;	/* measured files readcount */
Eric> -	unsigned int writecount;/* measured files writecount */
Eric>  	struct kref refcount;	/* ima_iint_cache reference count */
Eric>  };
 
Eric> diff --git a/security/integrity/ima/ima_iint.c b/security/integrity/ima/ima_iint.c
Eric> index db71a13..e68891f 100644
Eric> --- a/security/integrity/ima/ima_iint.c
Eric> +++ b/security/integrity/ima/ima_iint.c
Eric> @@ -129,11 +129,6 @@ void iint_free(struct kref *kref)
iint-> readcount);
iint-> readcount = 0;
Eric>  	}
Eric> -	if (iint->writecount != 0) {
Eric> -		printk(KERN_INFO "%s: writecount: %u\n", __func__,
Eric> -		       iint->writecount);
Eric> -		iint->writecount = 0;
Eric> -	}
Eric>  	kref_init(&iint->refcount);
Eric>  	kmem_cache_free(iint_cache, iint);
Eric>  }
Eric> @@ -166,7 +161,6 @@ static void init_once(void *foo)
iint-> flags = 0UL;
Eric>  	mutex_init(&iint->mutex);
iint-> readcount = 0;
Eric> -	iint->writecount = 0;
Eric>  	kref_init(&iint->refcount);
Eric>  }
 
Eric> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
Eric> index 2f9b5d5..24660bf 100644
Eric> --- a/security/integrity/ima/ima_main.c
Eric> +++ b/security/integrity/ima/ima_main.c
Eric> @@ -94,8 +94,6 @@ static void ima_inc_counts(struct ima_iint_cache *iint, fmode_t mode)
 
Eric>  	if ((mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
iint-> readcount++;
Eric> -	if (mode & FMODE_WRITE)
Eric> -		iint->writecount++;
Eric>  }
 
Eric>  /*
Eric> @@ -173,18 +171,16 @@ static void ima_dec_counts(struct ima_iint_cache *iint, struct inode *inode,
iint-> readcount--;
Eric>  	}
Eric>  	if (mode & FMODE_WRITE) {
Eric> -		if (unlikely(iint->writecount == 0))
Eric> +		if (atomic_read(&inode->i_writecount) <= 0)
Eric>  			dump = true;
Eric> -		iint->writecount--;
Eric> -		if (iint->writecount == 0) {
Eric> -			if (iint->version != inode->i_version)
Eric> -				iint->flags &= ~IMA_MEASURED;
Eric> -		}
Eric> +		if (atomic_read(&inode->i_writecount) == 1 &&
Eric> +		    iint->version != inode->i_version)
Eric> +			iint->flags &= ~IMA_MEASURED;
Eric>  	}
 
Eric>  	if (dump && !ima_limit_imbalance(file)) {
Eric> -		printk(KERN_INFO "%s: open/free imbalance (r:%u w:%u)\n",
Eric> -		       __func__, iint->readcount, iint->writecount);
Eric> +		printk(KERN_INFO "%s: open/free imbalance (r:%u)\n",
Eric> +		       __func__, iint->readcount);
Eric>  		dump_stack();
Eric>  	}
Eric>  }

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

-- 

  reply	other threads:[~2010-10-25 19:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25 18:41 [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache Eric Paris
2010-10-25 18:41 ` [PATCH 02/11] IMA: drop the inode opencount since it isn't needed for operation Eric Paris
2010-10-25 18:41 ` [PATCH 03/11] IMA: use unsigned int instead of long for counters Eric Paris
2010-10-25 18:41 ` [PATCH 04/11] IMA: convert internal flags from long to char Eric Paris
2010-10-25 18:41 ` [PATCH 05/11] IMA: use inode->i_lock to protect read and write counters Eric Paris
2010-10-25 18:41 ` [PATCH 06/11] IMA: use i_writecount rather than a private counter Eric Paris
2010-10-25 19:27   ` John Stoffel [this message]
2010-10-25 21:52     ` Eric Paris
2010-10-25 22:25       ` H. Peter Anvin
2010-10-25 22:29         ` Eric Paris
2010-10-26 13:57           ` John Stoffel
2010-10-26 13:53       ` John Stoffel
2010-10-26 22:08         ` H. Peter Anvin
2010-10-25 18:41 ` [PATCH 07/11] IMA: move read counter into struct inode Eric Paris
2010-10-25 18:42 ` [PATCH 08/11] IMA: only allocate iint when needed Eric Paris
2010-10-25 18:42 ` [PATCH 09/11] IMA: drop refcnt from ima_iint_cache since it isn't needed Eric Paris
2010-10-25 18:42 ` [PATCH 10/11] IMA: explicit IMA i_flag to remove global lock on inode_delete Eric Paris
2010-10-25 18:42 ` [PATCH 11/11] IMA: fix the ToMToU logic Eric Paris
2010-10-25 19:21 ` [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache John Stoffel
2010-10-25 19:38   ` J.H.
2010-10-25 20:55     ` Linus Torvalds
2010-10-25 20:57       ` Christoph Hellwig
2010-10-25 21:11         ` Linus Torvalds
2010-10-26 14:01           ` John Stoffel
2010-10-26 15:22             ` Linus Torvalds
2010-10-26 15:30               ` Eric Paris
2010-10-26 15:53               ` John Stoffel
2010-10-26 18:13               ` Al Viro
2010-10-27 13:35                 ` James Morris
2010-10-26 14:07       ` John Stoffel
2010-10-25 21:34   ` Eric Paris
2010-10-26 13:45     ` John Stoffel
2010-10-25 23:22 ` Dave Chinner
2010-10-26  0:12   ` Eric Paris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19653.55831.692904.538148@quad.stoffel.home \
    --to=john@stoffel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=warthog9@kernel.org \
    --cc=zohar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).