[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
On Thu, Jan 17, 2013 at 10:55 PM, Vivek Goyal <> wrote:
> On Thu, Jan 17, 2013 at 03:33:47PM -0500, Frank Ch. Eigler wrote:
>> Vivek Goyal <> 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
> More majordomo info at

 \ /
  Last update: 2013-01-17 23:24    [W:0.061 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site