Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

[Vivek Goyal <vgoyal@redhat.com>]

On Thu, Jan 17, 2013 at 11:46:57PM +0200, Kasatkin, Dmitry wrote:
> On Thu, Jan 17, 2013 at 10:55 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Thu, Jan 17, 2013 at 03:33:47PM -0500, Frank Ch. Eigler wrote:
> >> Vivek Goyal <vgoyal@redhat.com> writes:
> >>
> >> > [...]
> >> >> Can you please tell a bit more how this patch protect against direct
> >> >> writing to the blocks?
> >> >
> >> > If you have loaded all the pages from disk and locked them in memory and
> >> > verified the signature, then even if somebody modifies a block on disk
> >> > it does not matter. We will not read pages from disk anymore for this
> >> > exec(). We verified the signature of executable loaded in memory and
> >> > in-memory copy is intact.
> >>
> >> Does this imply dramatically increasing physical RAM pressure and load
> >> latency, because binaries (and presumably all their shared libraries)
> >> have to be locked & loaded?  (Else if they are paged out to
> >> encrypted-swap, is that sufficient protection against manipulation?)
> >
> > Even if you employ encrypted-swap, we still need to lock down any code
> > and data which lives in executable file on disk to avoid the case of
> > it being modified directly by writing to a block. Looks like IMA will not
> > detect that case.
> >
> 
> See my IMA patch I set today, which does locking the same way as you do.

Yes but I also mentioned that still there is little problem. Signature
verification should happen after the pages have been locked and not
before that.

Also I was thinking about encrypted swap. Any root process will have access
to encrypted swap? If yes, then it atleast does not work for the use case
I am trying to solve.

By selectively signing root executable, I am differentiating it with rest
of the root executable and not trusting root process here till it is
signed. So if another root process can get to swap and modify its contents
and it modified the address space of signed process. 

So for the use case I am trying to solve, encrypted swap is not the
solution. We have to lock down all of the process memory.

Thanks
Vivek