[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130116163453.GD29845@redhat.com>
Date: Wed, 16 Jan 2013 11:34:53 -0500
From: Vivek Goyal <vgoyal@...hat.com>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org, pjones@...hat.com, hpa@...or.com,
dhowells@...hat.com, jwboyer@...hat.com,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
On Wed, Jan 16, 2013 at 10:33:11AM -0500, Mimi Zohar wrote:
> On Wed, 2013-01-16 at 09:48 -0500, Vivek Goyal wrote:
> > On Wed, Jan 16, 2013 at 09:00:59AM -0500, Mimi Zohar wrote:
> > > On Tue, 2013-01-15 at 23:10 -0800, Eric W. Biederman wrote:
> > > > Mimi Zohar <zohar@...ux.vnet.ibm.com> writes:
> > > >
> > > > > Please remind me why you can't use IMA-appraisal, which was upstreamed
> > > > > in Linux 3.7? Why another method is needed?
> > > >
> > > > Good question Vivek?
> >
> > - IMA did not have any method to lock down signed binary pages in memory.
> > So while contents on disk could be verified, one could still modify
> > process memory contents by modifying swap. And IMA does not seem to
> > have any mechanism to protect against that.
>
> The kernel itself protects executables from being modified by calling
> try_module_get().
try_module_get() just takes a reference on module, isn't it? So in this
case take reference on binary loader module.
> The call to security_bprm_check() is immediately before this call.
I read the comment in ima_bprm_check() being called from security_bprm_check().
It says that files already open for write can't executed and files already
open for exec can't be open for writes. That's fine.
I was worried about anonymous pages being modified on swap and then
faulted back in. It is not necessarily signature verification but making
sure signed processes memory is not modified later by any unsigned process
in anyway. And that includes disabling ptrace too.
So IMA stuff does not do anything to protect against process memory being
modified using ptrace or by playing tricks with swap.
I am not sure what will happen if I can bypass the file system and directly
write on a disk block and modify executable. (Assuming one can get block
information somehow). Does anything protect such modification? Will IMA
detect it?
Thanks
Vivek
--
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