From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Roberto Sassu <roberto.sassu@polito.it>,
Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
Kees Cook <keescook@chromium.org>,
kexec@lists.infradead.org,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
horms@verge.net.au, "Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Matthew Garrett <mjg@redhat.com>, Dave Young <dyoung@redhat.com>,
Khalid Aziz <khalid@gonehiking.org>
Subject: Re: Kdump with signed images
Date: Thu, 1 Nov 2012 10:43:04 -0400 [thread overview]
Message-ID: <20121101144304.GA15821@redhat.com> (raw)
In-Reply-To: <1351780159.15708.17.camel@falcor>
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> >
> > [..]
> > > >
> > > > > - 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.
> > >
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > >
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > >
> > > ************************************************************************
> > > 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.
> > > *************************************************************************
> > >
> > > Thoughts?
> >
> > Eric responded but my mistake he responded to only me. So I will quickly
> > put his idea here.
> >
> > [start quote]
> >
> > You can't ptrace a process that has a capability you don't.
> >
> > That should be enforced in security/commoncap/
> >
> > [end quote]
> >
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
>
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."
Only those executables which have extended capability
(say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall.
Only signed executables will get this capability upon signature verification
(using keys in kernel keyring only).
so any xyz executable will not be able to call kexec_load() until and
unless it is signed with keys kernel trusts. This is similar to signed
module verification.
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Matthew Garrett <mjg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Khalid Aziz <khalid@gonehiking.org>,
kexec@lists.infradead.org, horms@verge.net.au,
Dave Young <dyoung@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
Roberto Sassu <roberto.sassu@polito.it>,
Kees Cook <keescook@chromium.org>
Subject: Re: Kdump with signed images
Date: Thu, 1 Nov 2012 10:43:04 -0400 [thread overview]
Message-ID: <20121101144304.GA15821@redhat.com> (raw)
In-Reply-To: <1351780159.15708.17.camel@falcor>
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> >
> > [..]
> > > >
> > > > > - 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.
> > >
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > >
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > >
> > > ************************************************************************
> > > 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.
> > > *************************************************************************
> > >
> > > Thoughts?
> >
> > Eric responded but my mistake he responded to only me. So I will quickly
> > put his idea here.
> >
> > [start quote]
> >
> > You can't ptrace a process that has a capability you don't.
> >
> > That should be enforced in security/commoncap/
> >
> > [end quote]
> >
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
>
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."
Only those executables which have extended capability
(say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall.
Only signed executables will get this capability upon signature verification
(using keys in kernel keyring only).
so any xyz executable will not be able to call kexec_load() until and
unless it is signed with keys kernel trusts. This is similar to signed
module verification.
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?
Thanks
Vivek
next prev parent reply other threads:[~2012-11-01 14:43 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 3:10 [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting Dave Young
2012-10-18 14:56 ` Khalid Aziz
2012-10-18 19:11 ` Vivek Goyal
2012-10-18 19:22 ` Khalid Aziz
2012-10-18 19:38 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Vivek Goyal
2012-10-18 19:55 ` Matthew Garrett
2012-10-18 22:25 ` Eric W. Biederman
2012-10-19 2:06 ` Vivek Goyal
2012-10-19 3:36 ` Eric W. Biederman
2012-10-19 14:31 ` Vivek Goyal
2012-10-22 20:43 ` Vivek Goyal
2012-10-22 21:11 ` Eric W. Biederman
2012-10-23 2:04 ` Simon Horman
2012-10-23 13:24 ` Vivek Goyal
2012-10-23 16:26 ` [RFC] Kdump with signed images Eric W. Biederman
2012-10-23 17:39 ` Vivek Goyal
2012-10-23 19:11 ` Maxim Uvarov
2012-10-23 19:16 ` Vivek Goyal
2012-10-22 21:07 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Eric W. Biederman
2012-10-23 13:18 ` Vivek Goyal
2012-10-23 14:59 ` Vivek Goyal
2012-10-23 15:41 ` Matthew Garrett
2012-10-23 16:44 ` [RFC] Kdump with signed images Eric W. Biederman
2012-10-23 16:52 ` Matthew Garrett
2012-10-24 17:19 ` Vivek Goyal
2012-10-24 17:19 ` Vivek Goyal
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 6:44 ` Kees Cook
2012-10-25 6:44 ` Kees Cook
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 19:06 ` Mimi Zohar
2012-10-25 19:06 ` Mimi Zohar
2012-10-25 15:39 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Vivek Goyal
2012-10-25 15:39 ` Vivek Goyal
2012-10-23 16:19 ` Kdump with signed images Eric W. Biederman
2012-10-23 16:31 ` Matthew Garrett
2012-10-23 17:03 ` Eric W. Biederman
2012-10-23 17:09 ` Matthew Garrett
2012-10-24 17:36 ` Vivek Goyal
2012-10-24 17:36 ` Vivek Goyal
2012-10-25 6:10 ` Mimi Zohar
2012-10-25 6:10 ` Mimi Zohar
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:55 ` Vivek Goyal
2012-10-25 18:55 ` Vivek Goyal
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 17:06 ` Vivek Goyal
2012-10-26 17:06 ` Vivek Goyal
2012-10-26 18:37 ` Mimi Zohar
2012-10-26 18:37 ` Mimi Zohar
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:43 ` Vivek Goyal [this message]
2012-11-01 14:43 ` Vivek Goyal
2012-11-01 14:52 ` Matthew Garrett
2012-11-01 14:52 ` Matthew Garrett
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:36 ` Vivek Goyal
2012-11-02 14:36 ` Vivek Goyal
2012-11-03 3:02 ` Balbir Singh
2012-11-03 3:02 ` Balbir Singh
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:32 ` Eric W. Biederman
2012-11-02 21:32 ` Eric W. Biederman
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 23:01 ` H. Peter Anvin
2012-11-05 23:01 ` H. Peter Anvin
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 23:51 ` Eric W. Biederman
2012-11-06 23:51 ` Eric W. Biederman
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 21:03 ` Eric W. Biederman
2012-11-08 21:03 ` Eric W. Biederman
2012-11-09 14:39 ` Vivek Goyal
2012-11-09 14:39 ` Vivek Goyal
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 12:56 ` Mimi Zohar
2012-11-15 12:56 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 16:23 ` Matthew Garrett
2012-11-01 16:23 ` Matthew Garrett
2012-11-02 16:57 ` Khalid Aziz
2012-11-02 16:57 ` Khalid Aziz
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:25 ` Mimi Zohar
2012-10-26 18:25 ` Mimi Zohar
2012-10-23 15:51 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Eric W. Biederman
2012-10-23 17:18 ` Vivek Goyal
2012-10-19 17:53 ` Vivek Goyal
2012-10-22 21:15 ` Eric W. Biederman
2012-11-02 21:36 ` H. Peter Anvin
2012-11-05 18:11 ` Vivek Goyal
2012-11-05 19:54 ` Eric W. Biederman
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=20121101144304.GA15821@redhat.com \
--to=vgoyal@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=khalid@gonehiking.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=roberto.sassu@polito.it \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.