linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	James Morris <jmorris@namei.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL
Date: Thu, 21 Mar 2013 09:43:48 -0400	[thread overview]
Message-ID: <20130321134348.GA3934@redhat.com> (raw)
In-Reply-To: <1363814289.2553.41.camel@x230.sbx07502.somerma.wayport.net>

On Wed, Mar 20, 2013 at 09:18:10PM +0000, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote:
> > On Wed, 2013-03-20 at 20:37 +0000, Matthew Garrett wrote:
> > > Right, that'd be the rough idea. Any further runtime policy updates
> > > would presumably need to be signed with a trusted key.
> > 
> > I'm really sorry to belabor this point, but can kexec rely on an LSM
> > label to identify a specific file, out of all the files being executed,
> > in a secure boot environment?  The SELinux integrity rule for kexec
> > would then look something like,
> >
> > appraise func=BPRM_CHECK obj_type=kdump_exec_t appraise_type=imasig
> 
> It would certainly be possible to configure a system such that this was
> true (assuming support for signed initramfs and restricted policy
> loading), and anyone wanting to ensure that kexec only loaded trusted
> binaries would have to ensure that their system was appropriately
> configured. Having some mechanism to then give the kexec binary
> CAP_MODIFY_KERNEL would avoid needing an extra kexec entry point.

Giving CAP_MODIFY_KERNEL to processess upon signature verification
will simplify things a bit.

Only thing is that signature verification alone is not sufficient. We
also need to make sure after signature verification executable can
not be modified in memory in any way. So that means atleast couple of
things.

- Process code/data should not be swapped out. Otherwise it can possibly
  be written by unsigned priviliged processes and then faulted in back.

- Because priviliged unsigned processes can bypass file system and
  directly write to disk, do not cache appraisal results. So create a
  way in IMA rules to not cache the results.

I think memory locking part is little tricky as what part of files are
to be locked will depend on the binary loader (and not IMA). May be IMA
can set a flag somewhere which gives an hint to binary loader that lock
down file. Once the file has been locked down, binary loader should
set some flag too and call security hook. This flag will be a hint to IMA
that file has been locked down, another appraisal happens and if
it passes successfuly, then IMA can give CAP_MODIFY_KERNEL capability
to the process.

Another small nit is appraise_type=imasig. Given the fact that there
can be many formats of digital signature, we might have to make it
more fine grained to be able to specify a particular kind of digital
signature and not every possible digital signature supported. 

Assuming all this works, I can look into how /sbin/kexec can call into
kernel to verify integrity of bzImage before it is loaded. Not sure one
needs to very PE/COFF signature or bzImage will be re-signed using IMA
and one needs to call into IMA. I think here also we will have to first
lock down file in memory, make sure nobody can open file for writes,
and then do signature verification. 

Thanks
Vivek

  reply	other threads:[~2013-03-21 13:43 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-18 21:32 [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Matthew Garrett
2013-03-18 21:32 ` [PATCH 02/12] SELinux: define mapping for CAP_COMPROMISE_KERNEL Matthew Garrett
2013-03-18 21:32 ` [PATCH 03/12] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett
2013-03-18 21:32 ` [PATCH 04/12] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett
2013-03-18 21:32 ` [PATCH 05/12] PCI: Require CAP_COMPROMISE_KERNEL for PCI BAR access Matthew Garrett
2013-03-27 15:03   ` Josh Boyer
2013-03-27 15:08     ` Kyle McMartin
2013-03-28 12:46       ` Josh Boyer
2013-03-18 21:32 ` [PATCH 06/12] x86: Require CAP_COMPROMISE_KERNEL for IO port access Matthew Garrett
2013-03-20  1:00   ` H. Peter Anvin
2013-03-18 21:32 ` [PATCH 07/12] ACPI: Limit access to custom_method Matthew Garrett
2013-03-18 21:32 ` [PATCH 08/12] asus-wmi: Restrict debugfs interface Matthew Garrett
2013-03-18 21:32 ` [PATCH 09/12] Require CAP_COMPROMISE_KERNEL for /dev/mem and /dev/kmem access Matthew Garrett
2013-03-18 21:32 ` [PATCH 10/12] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment Matthew Garrett
2013-03-19  8:47   ` Dave Young
2013-03-19 11:19     ` Josh Boyer
2013-03-19 17:07       ` [PATCH v2] " Josh Boyer
2013-03-18 21:32 ` [PATCH 11/12] x86: Require CAP_COMPROMISE_KERNEL for MSR writing Matthew Garrett
2013-03-18 21:32 ` [PATCH 12/12] kexec: Require CAP_SYS_COMPROMISE_KERNEL Matthew Garrett
2013-03-19  4:47 ` [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL James Morris
2013-03-20  1:03   ` H. Peter Anvin
2013-03-20 16:41   ` Mimi Zohar
2013-03-20 16:49     ` Matthew Garrett
2013-03-20 18:01       ` Mimi Zohar
2013-03-20 18:12         ` Matthew Garrett
2013-03-20 19:16           ` Mimi Zohar
2013-03-20 20:37             ` Matthew Garrett
2013-03-20 21:11               ` Mimi Zohar
2013-03-20 21:18                 ` Matthew Garrett
2013-03-21 13:43                   ` Vivek Goyal [this message]
2013-03-21 15:37                     ` Serge E. Hallyn
2013-03-21 15:52                       ` Vivek Goyal
2013-03-21 15:58                         ` Serge E. Hallyn
2013-03-21 16:04                           ` Vivek Goyal
2013-03-21 16:19                             ` Serge E. Hallyn
2013-03-21 17:15                               ` Vivek Goyal
2013-03-21  1:58     ` James Morris
2013-03-19  7:18 ` Yves-Alexis Perez
2013-03-20  1:02 ` H. Peter Anvin
2013-03-20  1:05   ` H. Peter Anvin
2013-03-20 13:15   ` Matthew Garrett
2013-03-20 15:03     ` H. Peter Anvin
2013-03-20 15:14       ` Matthew Garrett
2013-03-20 16:45         ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2013-03-20  1:07 Matthew Garrett
2013-03-20  1:11 ` H. Peter Anvin
2013-03-20  1:09 Matthew Garrett
2013-03-20  1:28 Matthew Garrett
2013-03-20  2:48 ` H. Peter Anvin
2013-03-20  3:08   ` H. Peter Anvin
2013-03-20  3:18     ` Alex Williamson
2013-03-20  3:22       ` H. Peter Anvin
2013-03-20  3:27         ` Alex Williamson
2013-03-21 16:32 Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130321134348.GA3934@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).