linux-kernel - Re: [RFC] 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-next>] [day] [month] [year] [list]

Date:	Wed, 24 Oct 2012 13:19:26 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Matthew Garrett <mjg@...hat.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>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Subject: Re: [RFC] Kdump with signed images

On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg@...hat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> >
> >> But what about creation of a new program which can call kexec_load()
> >> and execute an unsigned kernel. Doesn't look like that will be
> >> prevented using IMA.
> >
> > Right. Trusting userspace would require a new system call that passes in 
> > a signature of the userspace binary, and the kernel would then have to 
> > verify the ELF object in memory in order to ensure that it 
> > matches the signature. Verifying that the copy on the filesystem is 
> > unmodified isn't adequate - an attacker could simply have paused the 
> > process and injected code. 
> 
> Verifying the copy on the filesystem at exec time is perfectly adequate
> for gating extra permissions.  Certainly that is the model everywhere
> else in the signed key chain.
> 
> Where IMA falls short is there is no offline signing capability in IMA
> itself.  I think EVM may fix that.

[ CCing lkml. I think it is a good idea to open discussion to wider
audience. Also CCing IMA/EVM folks ]

Based on reading following wiki page, looks like EVM also does not allow
offline signing capability. And EVM is protecting IMA data to protect
against offline attack. If we can assume that unisgned kernels can't be
booted on the platform, then EVM might not be a strict requirement in
this case.

So as you said, one of the main problem with IMA use to verify /sbin/kexec
is that IMA does not provide offline signing capability.

> 
> > Realistically, the only solution here is for 
> > the kernel to verify that the kernel it's about to boot is signed and 
> > for it not to take any untrusted executable code from userspace.
> 
> Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> perfectly reasonable, and realistic.  In fact finding a way to trust
> small bits of userspace even if root is compromised seems a far superior
> model to simply solving the signing problem for /sbin/kexec.
> 
> Although I do admit some part of the kexec process will need to verify
> keys on the images we decide to boot.

It should be an option, isn't it? Either /sbin/kexec can try to verify the
integrity of kernel or we extend try to extend kexec() system call to also
pass the signature of kernel and let kernel verify it (as you mentioned
previously).

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/