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: <CALLzPKaizfTZCh3A0w8-RyAy4qwgXSyckYpHttrUawLnmYjFGw@mail.gmail.com>
Date:	Thu, 17 Jan 2013 23:46:57 +0200
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Vivek Goyal <vgoyal@...hat.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 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.

- Dmitry

> 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-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/