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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jan 2013 16:52:37 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, pjones@...hat.com, hpa@...or.com,
	dhowells@...hat.com, jwboyer@...hat.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 Thu, Jan 17, 2013 at 11:46:57PM +0200, Kasatkin, Dmitry wrote:
> On Thu, Jan 17, 2013 at 10:55 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > On Thu, Jan 17, 2013 at 03:33:47PM -0500, Frank Ch. Eigler wrote:
> >> Vivek Goyal <vgoyal@...hat.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
--
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/