linux-kernel - Re: Kdump with signed images

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: <20121026170609.GB24687@redhat.com>
Date:	Fri, 26 Oct 2012 13:06:09 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Eric W. Biederman" <ebiederm@...ssion.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>
Subject: Re: Kdump with signed images

On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> 
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.

- So say we can sign /sbin/kexec at build time and distros can do that.
- Verify the signature at exec time using kernel keyring and if
  verification happens successfully, say process gains extra capability.
- Use this new capability to determine whether kexec_load() will be
  successful or not.

Even if we can do all this, it still has the issue of being able to
stop the process in user space and replace the code at run time
and be able to launch unsigned kernel.

So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).
  
Thanks
Vivek
--
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/