[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ehjvfo4g.fsf@xmission.com>
Date: Wed, 14 Nov 2012 21:09:51 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Matthew Garrett <mjg@...hat.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Khalid Aziz <khalid@...ehiking.org>, kexec@...ts.infradead.org,
horms@...ge.net.au, Dave Young <dyoung@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
Roberto Sassu <roberto.sassu@...ito.it>,
Kees Cook <keescook@...omium.org>,
Peter Jones <pjones@...hat.com>
Subject: Re: Kdump with signed images
Vivek Goyal <vgoyal@...hat.com> writes:
> On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@...hat.com> writes:
>>
>> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
>> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
>> >>
>> >> [..]
>> >>
>> >> Thnking more about executable signature verification, I have another question.
>> >>
>> >> While verifyign the signature, we will have to read the whole executable
>> >> in memory. That sounds bad as we are in kernel mode and will not be killed
>> >> and if sombody is trying to execute a malformed exceptionally large
>> >> executable, system will start killing other processess. We can potentially
>> >> lock all the memory in kernel just by trying to execute a signed huge
>> >> executable. Not good.
>> >>
>> >
>> > Also, even if we try to read in whole executable, can't an hacker modify
>> > pages in swap disk and then they will be faulted back in and bingo hacker
>> > is running its unsigned code. (assuming root has been compromised otherwise
>> > why do we have to do all this exercise).
>>
>> You make a decent case for an implicit mlockall(MCL_FUTURE) being
>> required of signed executables, that are going to be granted privileges
>> based on signature verification.
>
> implicity lockall for signed executables sounds reasonable to avoid the
> swap hack.
>
>>
>> As for size if the executable won't fit in memory, there is no point in
>> checking the signature.
>
> Well I am worried about malformed executables. One can sign a huge
> executable (which is never meant to run successfully) and cause all
> kind of memory issues.
Good point what to do with executables with invalid sigantures. From
another reply it sounded like one of the bits of IMA/EVM had already
addressed part of that.
> Can we first look at the signature, decrypt it using certificates in
> kernel ring, and if we find out that executable was signed by any
> of the certificates, only then we go on to read in whole executable
> and try to calculate the digest. May be at the time of signing we can put
> a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> decryption we can check if LINUX is there and if yes, we know it was
> signed by the certifcate loaded in kernel and then go on to load the
> full executable and calculate digest.
> Not sure if above is doable or not but if it is, it might reduce the
> risk significantly as we will not try to integrity verify executables
> not signed by genuine certificates.
Known plaintext in the signed blob should allow that. I would be very
careful with that because it sounds like the kind of thing that opens
you up to plain-text attacks, but that is mostly my parania and lack of
experience speaking.
>> It should be fairly straight forward to make the signature checking
>> process preemptable and killable.
>
> hmm..., not sure how to do this. Will have to read more code to understand
> process killing and see what can I do this while I am in kernel mode
> and I possibly might have done kernel memory allocations using
> vmalloc()/kmalloc() etc.
Well basically it is matter of using the killable version of waits
returning an error code as you unwind, and eventually either
force_sig(SIGKILL) or do_exit().
There are a lot of times where you can support SIGKILL and just cause
the process to exit where you can't handle signals.
Eric
--
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/
Powered by blists - more mailing lists