linux-kernel - Re: [PATCH 01/12] Security: Add CAP_COMPROMISE

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: <20130321171556.GM3934@redhat.com>
Date:	Thu, 21 Mar 2013 13:15:56 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

On Thu, Mar 21, 2013 at 11:19:52AM -0500, Serge E. Hallyn wrote:

[..]
> > I am hoping I did not miss your point entirely.
> 
> No, you didn't.  If replay attacks are not a concern then that bit
> doesn't matter.  But if^Wwhen there is a vulnerability in a signed kernel,
> and a user has a copy of bzImage sitting around, signed kexec alone does
> not suffice (and I'm assuming revocation is not going into the kernel?).
> It seems to me if replay attacks are ignored, this is all for theater...
> 

As matthew mentioned, revocation list is in kernel. So old vulnerable
kernels should fail signature verification.

> The other concern is analogous, just more general - seems like I may very
> well be able to find a way to corrupt kexec or even corrupt the kernel with
> a bad environment.
> 
> So I'm just saying that in general it doesn't seem worth having a special
> list of capabilities that only signed executables can have, without doing 
> something about the environment.

Agreed that only being signed is part of the problem. Environment is
important too. And running signed binaries memory locked is I think
one part of controlling the environment. But there might be other
things too which I am blissfully unaware of.

Right now there were few things we were considering for controlling
the environemnt.

- Build /sbin/kexec statically and sign only statically linked exeutables.
- Run executables memory locked
- Unsigned binary can not ptrace() signed one.

> And that the solution to that seems like
> what we can already do today (with a bounding set and init-launched
> services).

Frankly speaking I did not understand this part. For secureboot issue
we don't trust root and don't trust init. I am assuming any restricted
environment setup will have to be done by a trusted entity.

> 
> All of this is probably premature though.  IIUC the first thing you are
> after is a way to record on the file the fact that it is a verified-signature
> binary, and that's what CAP_SIGNED meant right?

Yes, that was the first thing. How to reliably sign and verify signature
of a executable. Also make sure executable code/data can not modified
in memory later by anything untrusted.

>   I agree we need something
> like that, but using a capability is not right.  You can add a field to
> the binprm or file or f_cred, or even add a field to the capability struct,
> meaningful only on files, to show it was signed - but not taint the list of
> capabilities with something that is not a capability. 

Ok, I will look into other options too. Agreed being signed is not a
capability. But being signed along with other attributes should allow to 
get one a capability (CAP_MODIFY_KERNEL in this case). I am not sure why
nobody likes that idea. But that's fine, I will go with advice of subject
matter experts.

> I haven't looked
> closer to see which would be the best way (my hunch would be binprm), will 
> be happy to come up with a proposal when I have time, but I don't want to slow
> you down :)

Any suggetions are greatly appreciated whenever time permits. In the mean
time I will atleast write more code and post it for RFC and hopefully
there will be some consensus on how to solve kexec issue.

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/