Vivek Goyal <vgoyal at redhat.com> writes: > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: >> Vivek Goyal <vgoyal at redhat.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
