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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20130117205543.GA6133@redhat.com>
Date:	Thu, 17 Jan 2013 15:55:43 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.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 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.

May be we can only lock down any information which is loaded from
executable file. Rest of the pages can be swapped to encrypted swap.

As long as number of signed binaries are small, I think RAM pressure might
not be a problem but yes, if we sign everything, it will become an issue.

I am not sure how kernel can enforce the requirement of encrypted swap. If
we leave it to user as a recommendation, then we have the potential that
some hacker can bypass the whole thing. So it is not enforceable.

May be there could be a config option if that's enabled swapping works only
if it is encrypted. 

So locking few select statically compiled executables completely in memory
I think should not be too much of trouble and solve the problem I have at
hand.

For the more generic case of completely locked system, we will have to
conditionally modify the code to lock only any info loaded from executable 
and allow swapping other data to encrypted swap. This one we can look into
once somebody really wants to use 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/