lkml.org 
[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
From
On Wed, Jan 16, 2013 at 11:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Jan 16, 2013 at 02:24:50PM -0500, Mimi Zohar wrote:
> [..]
>> > > Sorry, this is out of scope for IMA. Dmitry has looked into this, but
>> > > I'm not sure where it stands at the moment.
>> >
>> > Ok, so that's one reason that why I wrote these patcehs. IMA currently
>> > is not doing following things to make sure address space of signed images
>> > is not modified by others.
>> >
>> > - Protecting against modifications to pages on swap.
>> > - Protecting against modifications by ptrace.
>> > - Protecting against modifications which bypassed filesystem and directly
>> > wrote to the block.
>> >
>> > Locking down all the pages of signed binaries in memory hopefully should
>> > solve above problems.
>>
>> Signing and verifying ELF executables goes back a long time ~2003/4,
>> from a number of esteemed kernel developers, including Greg-KH and Serge
>> Hallyn.
>>
>> IMA-appraisal isn't limited to appraising a single type of file, but is
>> a generic mechanism for appraising all files. If there are issues that
>> aren't being addressed, then by all means, please help by addressing
>> them. Duplicating a large portion of the code is not productive.
>
> So do you have ideas on how to address above mentioned issues. Do they
> fit into the realm of IMA/EVM or I just need to write separate code (which
> I have already done).
>
> With above issues, IMA stuff for executable files sounds incomplete.
>

swap is a last resort. healthy system uses swap minimally.
It is very easy to add /etc/crypttab which allows to have encrypted swap

# <target name> <source device> <key file> <options>
swap /dev/sda6 /dev/urandom swap

And it will eliminate plenty of possible attacks.
Processes have also RW data, modification of those will create huge
risk for the system...

But certain locking extensions like you implemented can be added to IMA as well.

It was said about ptrace already.


> - Protecting against modifications which bypassed filesystem and directly wrote to the block.

Can you please tell a bit more how this patch protect against direct
writing to the blocks?

Thanks,
Dmitry

> Thanks
> Vivek


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