On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
On Tue, Nov 06,
On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
[..]
Thnking more about executable signature
On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
[..]
Thnking more about executable signature verification, I have another question.
While verifyign the signature, we will have to read the whole executable
in memory. That sounds bad as we are in kernel mode and will not be
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
[..]
Thnking more about executable signature verification, I have another question.
While verifyign the signature, we will have to read the whole executable
in
On Thu, 2012-11-08 at 14:40 -0500, Vivek Goyal wrote:
On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
[..]
Thnking more about executable signature verification, I have another question.
While verifyign the signature, we will have to read the whole executable
in
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
[..]
Thnking more about executable signature verification, I have another
question.
While verifyign the signature, we
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
It needs to be checked but /sbin/kexec should not use any functions that
trigger nss switch. No user or password
Vivek Goyal vgo...@redhat.com writes:
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
It needs to be checked but /sbin/kexec should not use any functions that
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
So I think this does satisfy the requirement matthew
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
It needs to be checked but /sbin/kexec should not use any functions that
trigger nss switch. No user or password or host name lookup should be
happening.
I also think that we don't
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
It needs to be checked but /sbin/kexec should not use any functions that
trigger nss switch. No user or password
Yes, it is unlikely you can pare thibgs down more than klibc.
Vivek Goyal vgo...@redhat.com wrote:
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
It needs to be
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?
Sure, if you can ensure that. You'll need to figure out how
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you
On Thu, 2012-11-01 at 16:23 +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
How would a customer go about getting that userspace binary signed and
re-signed every time they update their app? There is the option of
turning the whole SecureBoot
Vivek Goyal vgo...@redhat.com writes:
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?
Sure, if you can
On 11/02/2012 07:29 AM, Balbir Singh wrote:
Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically
linked programs need some shared libraries which is not acceptable for
me. What can I do? Probably, worth trying.
You can build something with klibc... a static klibc binary can
On Fri, Oct 26, 2012 at 02:37:29PM -0400, Mimi Zohar wrote:
On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote:
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,
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
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
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?
Sure, if you can ensure that. You'll need to figure out how to get the
build system to sign the userspace binaries and you'll need
On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote:
On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
And if one wants only /sbin/kexec to call it, then just sign that
one so no other executable will be able to call kexec_load(). Though
I don't think that's the
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.
On Fri, 2012-10-26 at 03:39 +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
On Fri, 2012-10-26 at 19:19 +0100, Matthew Garrett wrote:
On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote:
On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
and it must be impossible for anything other than
/sbin/kexec to make the kexec system call.
Permission is
On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
[..]
There are 3 options for trusting /sbin/kexec. There
On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.com writes:
On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek
On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.com writes:
On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
[..]
IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels. Both 'security.ima' and 'security.evm' can contain digital
signatures.
But the
On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
[..]
IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels. Both 'security.ima' and
On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
[..]
IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata,
On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.com writes:
On
On Thu, 2012-10-25 at 14:55 -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
[..]
IMA-appraisal verifies the integrity of file
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,
Matthew Garrett m...@redhat.com writes:
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
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.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
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
Vivek Goyal vgo...@redhat.com writes:
On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
[..]
There are 3 options for trusting /sbin/kexec. There are IMA and EMA,
and it is conceivable to have ELF note
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.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
Vivek Goyal vgo...@redhat.com writes:
On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
[..]
There are 3 options for trusting /sbin/kexec. There are IMA and EMA,
and it is conceivable to have ELF note sections with signatures for
executables.
Can you please tell more
Vivek Goyal vgo...@redhat.com writes:
On Tue, Oct 23, 2012 at 11:04:29AM +0900, Simon Horman wrote:
On Mon, Oct 22, 2012 at 04:43:39PM -0400, Vivek Goyal wrote:
On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:
[..]
- What happens to purgatory code. It is unsigned piece of
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
No. UEFI secure boot has absolutely nothing todo with this.
UEFI secure boot is about not being able to hijack the code EFI runs
directly. Full stop.
No. It's about ensuring that no untrusted code can be run before any OS
Matthew Garrett m...@redhat.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
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
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
Matthew Garrett m...@redhat.com writes:
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
No. UEFI secure boot has absolutely nothing todo with this.
UEFI secure boot is about not being able to hijack the code EFI runs
directly. Full stop.
No. It's about ensuring that
On Tue, Oct 23, 2012 at 10:03:37AM -0700, Eric W. Biederman wrote:
Matthew Garrett m...@redhat.com writes:
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
No. UEFI secure boot has absolutely nothing todo with this.
UEFI secure boot is about not being able to hijack
On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote:
[..]
I think this will be a new parallel path and this new path should be taken
only on kernel booted with secure boot enabled. (Either automatically or
by using some kexec command line option). So nothing should be broken
On Tue, Oct 23, 2012 at 11:11:05PM +0400, Maxim Uvarov wrote:
2012/10/23 Vivek Goyal vgo...@redhat.com:
On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote:
[..]
I think this will be a new parallel path and this new path should be
taken
only on kernel booted with
47 matches
Mail list logo
