On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> 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 about what is EMA and IMA. I did quick google
> >> > > and could not find much.
> >> >
> >> > That should have been EVM and IMA. Look under security/integrity/. I
> >> > don't know much about them but they appear to be security modules with a
> >> > focus on verifying checksum or perhaps encrypted hashes of executables
> >> > are consistent.
> >>
> >> I will do some quick search there and I see if I can understand something.
> >>
> >
> > Ok, I quickly went through following paper.
> >
> > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> >
> > So it looks like that IMA can store the hashes of files and at execute
> > time ensure those hashes are unchanged to protect against the possibility
> > of modification of files.
> >
> > 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.
> >
> > Whole idea behind UEFI secure boot seems to be that all signing happens
> > outside the running system and now only signed code can run with higher
> > priviliges.
>
> 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.
>
> Some people would like to implment a security policy that says
> you can't boot an untrusted version of windows from linux if you have
> booted with UEFI secure boot, so they don't get their bootloader
> signatures revoked by microsoft.
>
> A security model relying on Microsoft's key is totally uniteresting to
> me. Either signing at the UEFI level is of no use or Microsofts key
> will fall again to the combined assult of every cracker and every
> governmental dirty cyber ops division attacking it. Not to mention that
> Microsoft has little incentive to keep linux booting.
>
> I think it is reasonable to be able to support a policy where we can't
> boot unsigned versions of Microsoft windows. However beyond being able
> to exclude booting windows being one criteria for our policy mechanism
> please don't even start to justify things with that ridiculous security
> policy even indirectly.
>
> > IMA seems to be only protecting against only making sure
> > existing binaries are not modifed but it does not seem to prevent against
> > installation of new binaries and these binaries take advantage of kexec
> > system call to load an unsigned kernel.
>
> I believe you can combine IMA with EVM signed security attributes where
> the EVM signing key is offline, and the verification key is in the
> kernel.
>
> The combination of IMA and EVM gets very close to being able to sign
> executables offline and be able to update them.
[ Again CCing lkml and IMA/EVM folks ]
After little reading, my understanding is EVM also does not support
offline signing.
http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page
Given the fact EVM protects IMA data (security.ima), which is generated
inline, I am not sure how EVM can sign images offline.
I might have misunderstood things, please correct me if that's not the
case.
Thanks
Vivek
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 <[email protected]> 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 about what is EMA and IMA. I did quick google
> > >> > > and could not find much.
> > >> >
> > >> > That should have been EVM and IMA. Look under security/integrity/. I
> > >> > don't know much about them but they appear to be security modules with a
> > >> > focus on verifying checksum or perhaps encrypted hashes of executables
> > >> > are consistent.
> > >>
> > >> I will do some quick search there and I see if I can understand something.
> > >>
> > >
> > > Ok, I quickly went through following paper.
> > >
> > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> > >
> > > So it looks like that IMA can store the hashes of files and at execute
> > > time ensure those hashes are unchanged to protect against the possibility
> > > of modification of files.
IMA-appraisal originally was hashed based, but Dmitry Kasatkin added
digital signature support. Both have been upstreamed.
> > > 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.
Assuming the IMA policy syntax is updated to require 'security.ima' to
contain a digital signature, then it is only a question of protecting
the _ima and _evm keyrings. (Dmitry has such a patch waiting to be
reviewed.) So the new program would have to be vetted by someone
trusted.
> > > Whole idea behind UEFI secure boot seems to be that all signing happens
> > > outside the running system and now only signed code can run with higher
> > > priviliges.
> >
> > 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.
> >
> > Some people would like to implment a security policy that says
> > you can't boot an untrusted version of windows from linux if you have
> > booted with UEFI secure boot, so they don't get their bootloader
> > signatures revoked by microsoft.
> >
> > A security model relying on Microsoft's key is totally uniteresting to
> > me. Either signing at the UEFI level is of no use or Microsofts key
> > will fall again to the combined assult of every cracker and every
> > governmental dirty cyber ops division attacking it. Not to mention that
> > Microsoft has little incentive to keep linux booting.
> >
> > I think it is reasonable to be able to support a policy where we can't
> > boot unsigned versions of Microsoft windows. However beyond being able
> > to exclude booting windows being one criteria for our policy mechanism
> > please don't even start to justify things with that ridiculous security
> > policy even indirectly.
> >
> > > IMA seems to be only protecting against only making sure
> > > existing binaries are not modifed but it does not seem to prevent against
> > > installation of new binaries and these binaries take advantage of kexec
> > > system call to load an unsigned kernel.
The IMA/IMA-appraisal policy dictates what needs to be appraised. The
default ima-appraisal policy appraises all files owned by root.
> > I believe you can combine IMA with EVM signed security attributes where
> > the EVM signing key is offline, and the verification key is in the
> > kernel.
> >
> > The combination of IMA and EVM gets very close to being able to sign
> > executables offline and be able to update them.
>
> [ Again CCing lkml and IMA/EVM folks ]
>
> After little reading, my understanding is EVM also does not support
> offline signing.
>
> http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page
>
> Given the fact EVM protects IMA data (security.ima), which is generated
> inline, I am not sure how EVM can sign images offline.
>
> I might have misunderstood things, please correct me if that's not the
> case.
>
> Thanks
> Vivek
>
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.
thanks,
Mimi
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 private key for creating these digital signature needs to be
on the target system?
Thanks
Vivek
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 'security.evm' can contain digital
> > signatures.
>
> But the private key for creating these digital signature needs to be
> on the target system?
>
> Thanks
> Vivek
Absolutely not. The public key needs to be added to the _ima or _evm
keyrings. Roberto Sassu modified dracut and later made equivalent
changes to systemd. Both have been upstreamed. Dmitry has a package
that labels the filesystem called ima-evm-utils, which supports hash
(IMA), hmac(EVM) and digital signatures(both).
We're hoping that distro's would label all immutable files, not only elf
executables, with digital signatures and mutable files with a hash.
thanks,
Mimi
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, such as LSM and IMA-appraisal
> > > labels. Both 'security.ima' and 'security.evm' can contain digital
> > > signatures.
> >
> > But the private key for creating these digital signature needs to be
> > on the target system?
> >
> > Thanks
> > Vivek
>
> Absolutely not. The public key needs to be added to the _ima or _evm
> keyrings. Roberto Sassu modified dracut and later made equivalent
> changes to systemd. Both have been upstreamed.
Putting public key in _ima or _evm keyring is not the problem. This is
just the verification part.
> Dmitry has a package
> that labels the filesystem called ima-evm-utils, which supports hash
> (IMA), hmac(EVM) and digital signatures(both).
>
> We're hoping that distro's would label all immutable files, not only elf
> executables, with digital signatures and mutable files with a hash.
So this labeling (digital signing) can happen at build time?
I suspect you need labeling to happen at system install time? If yes,
installer does not have the private key to sign anything.
IOW, if distro sign a file, they will most likely put signatures in
ELF header (something along the lines of signing PE/COFF binaries). But
I think you need digital signatures to be put in security.ima which are
stored in xattrs and xattrs are not generated till you put file in
question on target file system.
Thanks
Vivek
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 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 private key for creating these digital signature needs to be
> > > on the target system?
> > >
> > > Thanks
> > > Vivek
> >
> > Absolutely not. The public key needs to be added to the _ima or _evm
> > keyrings. Roberto Sassu modified dracut and later made equivalent
> > changes to systemd. Both have been upstreamed.
>
> Putting public key in _ima or _evm keyring is not the problem. This is
> just the verification part.
>
> > Dmitry has a package
> > that labels the filesystem called ima-evm-utils, which supports hash
> > (IMA), hmac(EVM) and digital signatures(both).
> >
> > We're hoping that distro's would label all immutable files, not only elf
> > executables, with digital signatures and mutable files with a hash.
>
> So this labeling (digital signing) can happen at build time?
There is nothing inherently preventing it from happening at build time.
Elana Reshetova gave a talk at LSS 2012 on modifying RPM
http://lwn.net/Articles/518265/.
> I suspect you need labeling to happen at system install time? If yes,
> installer does not have the private key to sign anything.
The installed system needs to be labeled, but how that occurs is
dependent on your environment (eg. flash, rpm based install). Neither
of these mechanisms would require the build private key.
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, calculated using a system unique key.
> IOW, if distro sign a file, they will most likely put signatures in
> ELF header (something along the lines of signing PE/COFF binaries).
Rusty was definitely against putting the signature in the ELF header for
kernel modules. Why would this be any different?
> But
> I think you need digital signatures to be put in security.ima which are
> stored in xattrs and xattrs are not generated till you put file in
> question on target file system.
>
> Thanks
> Vivek
The 'security.ima' digital signature would be created as part of the
build process and stored as an extended attribute with the file, like
other metadata. On install, the file, extended attributes and other
metadata would be copied to the target file system.
Mimi
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, calculated using a system unique key.
The idea isn't to prevent /sbin/kexec from being modified after
installation - it's to prevent it from being possible to install a
system that has a modified /sbin/kexec. Leaving any part of this up to
the package installer means that it doesn't solve the problem we're
trying to solve here. 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.
--
Matthew Garrett | [email protected]
Matthew Garrett <[email protected]> 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 signature would be
>> installed with an HMAC, calculated using a system unique key.
>
> The idea isn't to prevent /sbin/kexec from being modified after
> installation - it's to prevent it from being possible to install a
> system that has a modified /sbin/kexec. Leaving any part of this up to
> the package installer means that it doesn't solve the problem we're
> trying to solve here. 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.
The 'security.capability' attribute modulo weirdness with the security
bounding set gives us the necessary tools to allow /sbin/kexec to make
the system call.
The primary trick with this is to limit the installer in such as way
that we can trust the installer even on a system on which root has been
compromised.
Trusting the installer is the same class of problem as trusting
/sbin/kexec, and to me a much more interesting problem as it keeps
critical system files from being tampered with.
It sounds like there are some tricky details to work through but this
direction of system integrity looks like it is worth pursuing,
regardless of how we handle a signed /sbin/kexec.
Eric
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. The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key.
>
> The idea isn't to prevent /sbin/kexec from being modified after
> installation - it's to prevent it from being possible to install a
> system that has a modified /sbin/kexec. Leaving any part of this up to
> the package installer means that it doesn't solve the problem we're
> trying to solve here. 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.
I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.
- 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.
So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).
Thanks
Vivek
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 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key.
>
> The idea isn't to prevent /sbin/kexec from being modified after
> installation - it's to prevent it from being possible to install a
> system that has a modified /sbin/kexec.
Understood.
> Leaving any part of this up to
> the package installer means that it doesn't solve the problem we're
> trying to solve here. 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,
With Dmitry's patch "5e0d1a4 ima: added policy support for security.ima
type", or something similar, we can force 'security.ima' to a specific
type, in this case, a digital signature. With that patch, this
shouldn't be a problem.
> and it must be impossible for anything other than
> /sbin/kexec to make the kexec system call.
Permission is a MAC issue. :)
thanks,
Mimi
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 a MAC issue. :)
It's a MAC issue that has to be implemented in the kernel. We can't
depend on userspace loading any kind of policy.
--
Matthew Garrett | [email protected]
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 a MAC issue. :)
>
> It's a MAC issue that has to be implemented in the kernel. We can't
> depend on userspace loading any kind of policy.
Still a MAC issue, that problably could be addressed by capabilities. I
suggest you post this issue on the LSM mailing list. Please cc: Serge,
as the capabilities maintainer.
thanks,
Mimi
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, 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, calculated using a system unique key.
> >
> > The idea isn't to prevent /sbin/kexec from being modified after
> > installation - it's to prevent it from being possible to install a
> > system that has a modified /sbin/kexec. Leaving any part of this up to
> > the package installer means that it doesn't solve the problem we're
> > trying to solve here. 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.
>
> I am kind of lost now so just trying to summarize whatever I have
> learned so far from this thread.
Thanks for summarizing.
> - 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.
>
> So until and unless we have a good solution to verify application's
> integrity/authneticity at the time of kexec_load() system call we
> still have the problem. And I don't think we have come up with a
> solution for that yet (until and unless I missed something).
>
> Thanks
> Vivek
>
Agreed, you need a new LSM/integrity hook.
thanks,
Mimi
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, 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, calculated using a system unique key.
> > >
> > > The idea isn't to prevent /sbin/kexec from being modified after
> > > installation - it's to prevent it from being possible to install a
> > > system that has a modified /sbin/kexec. Leaving any part of this up to
> > > the package installer means that it doesn't solve the problem we're
> > > trying to solve here. 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.
> >
> > I am kind of lost now so just trying to summarize whatever I have
> > learned so far from this thread.
>
> Thanks for summarizing.
>
> > - 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?
Thanks
Vivek
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
Thanks
Vivek
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."
thanks,
Mimi
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
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."
I think what matthew might have meant that anything other than signed
trusted executable should not be able to call kexec_load(). Matthew?
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 requirement here. Requirement is that only
trusted executables should be able to call kexec_load().
Thanks
Vivek
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 to ensure
that they're statically linked and don't dlopen anything (including the
nsswitch modules), but otherwise that should work.
--
Matthew Garrett | [email protected]
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 requirement here. Requirement is that only
> trusted executables should be able to call kexec_load().
Where "trusted executables" means "signed by a key that's present in the
system firmware or in the kernel that's signed with a key that's present
in the system firmware", sure.
--
Matthew Garrett | [email protected]
On Thu, 2012-11-01 at 14:57 +0000, 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 requirement here. Requirement is that only
> > trusted executables should be able to call kexec_load().
>
> Where "trusted executables" means "signed by a key that's present in the
> system firmware or in the kernel that's signed with a key that's present
> in the system firmware", sure.
>
This is starting to sound too restrictive (even though I understand the
rationale behind the restrictions). Does this allow for a custom
userspace application that among other things also can kexec_load() a
new kernel and boot it, for example a customer unique health monitoring
app that reboots the system if things are not looking right on the
running system? 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 thing off for a system like
that but let us assume customer wants to leave that on or does not have
the option to turn it off?
--
Khalid
On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> On Thu, 2012-11-01 at 14:57 +0000, 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 requirement here. Requirement is that only
> > > trusted executables should be able to call kexec_load().
> >
> > Where "trusted executables" means "signed by a key that's present in the
> > system firmware or in the kernel that's signed with a key that's present
> > in the system firmware", sure.
> >
>
> This is starting to sound too restrictive (even though I understand the
> rationale behind the restrictions). Does this allow for a custom
> userspace application that among other things also can kexec_load() a
> new kernel and boot it, for example a customer unique health monitoring
> app that reboots the system if things are not looking right on the
> running system?
Only if it's signed with a key that the kernel trusts.
> 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 thing off for a system like that but let
> us assume customer wants to leave that on or does not have the option
> to turn it off?
There's ongoing work for providing mechanisms for trusting user keys. If
you want Secure Boot turned on, you don't want any untrusted code
running in your kernel. If you're happy with untrusted code in your
kernel, why are you using Secure Boot?
--
Matthew Garrett | [email protected]
On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
> build system to sign the userspace binaries and you'll need to ensure
> that they're statically linked and don't dlopen anything (including the
> nsswitch modules), but otherwise that should work.
>
[ CC peter jones ]
Ok, so even if we build kexec-tools statically with glibc, we have the
issue of name service switch modules. glibc will still do dlopen on
these modules. So what are options now.
- Sign glibc and associated shared libraries. Do not allow unsigned
shared library to dynamically link with signed executable.
- Peter mentioned that work with uClibc for kexec-tools.
I personally think that however hard it is but first option sounds like
a long term solution. We might have more user space processes which
we might have to trust a generic solution will help with that. For example,
we might have to sign and trust qemu at some point of time.
Are there other ways of handing glibc issue?
Thanks
Vivek
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <[email protected]> wrote:
> On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
>> build system to sign the userspace binaries and you'll need to ensure
>> that they're statically linked and don't dlopen anything (including the
>> nsswitch modules), but otherwise that should work.
>>
>
> [ CC peter jones ]
>
> Ok, so even if we build kexec-tools statically with glibc, we have the
> issue of name service switch modules. glibc will still do dlopen on
> these modules. So what are options now.
>
> - Sign glibc and associated shared libraries. Do not allow unsigned
> shared library to dynamically link with signed executable.
>
> - Peter mentioned that work with uClibc for kexec-tools.
>
> I personally think that however hard it is but first option sounds like
> a long term solution. We might have more user space processes which
> we might have to trust a generic solution will help with that. For example,
> we might have to sign and trust qemu at some point of time.
>
> Are there other ways of handing glibc issue?
>
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.
Balbir Singh
On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <[email protected]> wrote:
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
> >> build system to sign the userspace binaries and you'll need to ensure
> >> that they're statically linked and don't dlopen anything (including the
> >> nsswitch modules), but otherwise that should work.
> >>
> >
> > [ CC peter jones ]
> >
> > Ok, so even if we build kexec-tools statically with glibc, we have the
> > issue of name service switch modules. glibc will still do dlopen on
> > these modules. So what are options now.
> >
> > - Sign glibc and associated shared libraries. Do not allow unsigned
> > shared library to dynamically link with signed executable.
> >
> > - Peter mentioned that work with uClibc for kexec-tools.
> >
> > I personally think that however hard it is but first option sounds like
> > a long term solution. We might have more user space processes which
> > we might have to trust a generic solution will help with that. For example,
> > we might have to sign and trust qemu at some point of time.
> >
> > Are there other ways of handing glibc issue?
> >
>
> 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.
Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
and then individual programs need to statically build against the nss
modules program will use.
I think building libc with -enable-static-nss part will be unacceptable
for general server as other programs would like to make use of the
existing nss functionality.
Thanks
Vivek
On Thu, 2012-11-01 at 16:23 +0000, 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 thing off for a system like that but let
> > us assume customer wants to leave that on or does not have the option
> > to turn it off?
>
> There's ongoing work for providing mechanisms for trusting user keys. If
> you want Secure Boot turned on, you don't want any untrusted code
> running in your kernel. If you're happy with untrusted code in your
> kernel, why are you using Secure Boot?
>
I would argue code written by a customer to run on their own systems is
inherently trusted code and does not invalidate need/desire for Secure
Boot. So the customer will still need some way to get their binary
signed very painlessly just so they could use their own binary on their
own system, simply because of a heavily locked down system design by
Linux community.
--
Khalid
Vivek Goyal <[email protected]> writes:
> On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
>> build system to sign the userspace binaries and you'll need to ensure
>> that they're statically linked and don't dlopen anything (including the
>> nsswitch modules), but otherwise that should work.
>>
>
> [ CC peter jones ]
>
> Ok, so even if we build kexec-tools statically with glibc, we have the
> issue of name service switch modules. glibc will still do dlopen on
> these modules. So what are options now.
>
> - Sign glibc and associated shared libraries. Do not allow unsigned
> shared library to dynamically link with signed executable.
>
> - Peter mentioned that work with uClibc for kexec-tools.
>
> I personally think that however hard it is but first option sounds like
> a long term solution. We might have more user space processes which
> we might have to trust a generic solution will help with that. For example,
> we might have to sign and trust qemu at some point of time.
>
> Are there other ways of handing glibc issue?
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.
This is one part in hardening /sbin/kexec to deal with hostile root
users. We need to check crazy things like do the files we open on /proc
actually point to /proc after we have opened them.
I believe glibc has some code which triggers for suid root applications
that we should ensure gets triggered that avoid trusting things like
LD_LIBRARY_PATH and company.
Eric
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 easily
be smaller than a dynamic glibc binary.
-hpa
On Fri, Nov 2, 2012 at 8:06 PM, Vivek Goyal <[email protected]> wrote:
> On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
>> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <[email protected]> wrote:
>> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
>> >> build system to sign the userspace binaries and you'll need to ensure
>> >> that they're statically linked and don't dlopen anything (including the
>> >> nsswitch modules), but otherwise that should work.
>> >>
>> >
>> > [ CC peter jones ]
>> >
>> > Ok, so even if we build kexec-tools statically with glibc, we have the
>> > issue of name service switch modules. glibc will still do dlopen on
>> > these modules. So what are options now.
>> >
>> > - Sign glibc and associated shared libraries. Do not allow unsigned
>> > shared library to dynamically link with signed executable.
>> >
>> > - Peter mentioned that work with uClibc for kexec-tools.
>> >
>> > I personally think that however hard it is but first option sounds like
>> > a long term solution. We might have more user space processes which
>> > we might have to trust a generic solution will help with that. For example,
>> > we might have to sign and trust qemu at some point of time.
>> >
>> > Are there other ways of handing glibc issue?
>> >
>>
>> 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.
>
> Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
> and then individual programs need to statically build against the nss
> modules program will use.
>
> I think building libc with -enable-static-nss part will be unacceptable
> for general server as other programs would like to make use of the
> existing nss functionality.
No, use that library for static linking only for programs that need to
be signed (kexec-tools), until the base OS gets signature support. Why
does the same library need to be used for general sever programs? The
built library would be used only on the build system.
I also like HPA's suggestion on using klibc, but I am not sure what it
would take to port the tools to use klibc
Balbir
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> writes:
>
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, 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 to get the
> >> build system to sign the userspace binaries and you'll need to ensure
> >> that they're statically linked and don't dlopen anything (including the
> >> nsswitch modules), but otherwise that should work.
> >>
> >
> > [ CC peter jones ]
> >
> > Ok, so even if we build kexec-tools statically with glibc, we have the
> > issue of name service switch modules. glibc will still do dlopen on
> > these modules. So what are options now.
> >
> > - Sign glibc and associated shared libraries. Do not allow unsigned
> > shared library to dynamically link with signed executable.
> >
> > - Peter mentioned that work with uClibc for kexec-tools.
> >
> > I personally think that however hard it is but first option sounds like
> > a long term solution. We might have more user space processes which
> > we might have to trust a generic solution will help with that. For example,
> > we might have to sign and trust qemu at some point of time.
> >
> > Are there other ways of handing glibc issue?
>
> 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 call routines which trigger nss switch but
be probably can't rely on that as somebody might introduce it in
future. So we need more robust mechanism to prevent it than just code
inspection.
>
> This is one part in hardening /sbin/kexec to deal with hostile root
> users. We need to check crazy things like do the files we open on /proc
> actually point to /proc after we have opened them.
Can you please explain it more. How can one fiddle with /proc. Also
what's the solution then.
>
> I believe glibc has some code which triggers for suid root applications
> that we should ensure gets triggered that avoid trusting things like
> LD_LIBRARY_PATH and company.
I guess linking statically with uClibc or klibc (as hpa said), might turn
out to be better option to avoid all the issues w.r.t shared objects
and all the tricky environment variables.
Thanks
Vivek
Vivek Goyal <[email protected]> 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 call routines which trigger nss switch but
> be probably can't rely on that as somebody might introduce it in
> future. So we need more robust mechanism to prevent it than just code
> inspection.
The fact that we shouldn't use those routines is enough to let us
walk down a path where they are not used. Either with a static glibc
linked told to use no nss modules (--enable-static-nss ?), or with
another more restricted libc.
>> This is one part in hardening /sbin/kexec to deal with hostile root
>> users. We need to check crazy things like do the files we open on /proc
>> actually point to /proc after we have opened them.
>
> Can you please explain it more. How can one fiddle with /proc. Also
> what's the solution then.
The solution is to just fstat the files and verify the filesystem from
which they came after the files have been opened.
The issue is that an evil root user may have mounted something else on /proc.
>> I believe glibc has some code which triggers for suid root applications
>> that we should ensure gets triggered that avoid trusting things like
>> LD_LIBRARY_PATH and company.
>
> I guess linking statically with uClibc or klibc (as hpa said), might turn
> out to be better option to avoid all the issues w.r.t shared objects
> and all the tricky environment variables.
Linking with a more restricted libc will solve most if not all shared
object issues.
We still need to audit our environment variable issue. How we interpret
them and how our restricted libc automatically interprets them.
Eric
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> 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 call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
>
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used. Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.
Is there anything wrong with using uClibc? Trying to link again
customized glibc (with --enable-static-nss) sounds just extra work for
build environments. Are there know restricted libc or we need to create
one with passing more compile time options to libc.
Instead of doing more work in an attempt to create restricted libc,
it might be easier to just link against any already available
restricted library.
Thanks
Vivek
Yes, it is unlikely you can pare thibgs down more than klibc.
Vivek Goyal <[email protected]> wrote:
>On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <[email protected]> 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 call routines which trigger nss switch
>but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just
>code
>> > inspection.
>>
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used. Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
>Is there anything wrong with using uClibc? Trying to link again
>customized glibc (with --enable-static-nss) sounds just extra work for
>build environments. Are there know restricted libc or we need to create
>one with passing more compile time options to libc.
>
>Instead of doing more work in an attempt to create restricted libc,
>it might be easier to just link against any already available
>restricted library.
>
>Thanks
>Vivek
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> 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 call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
>
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used. Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.
I installed glibc-static and built kexec-tools using gcc "-static" option.
It built just fine and infact kdump is working with it.
Size of new kexec binary is around 1.4MB.
Did not get any warning w.r.t nss, so I am assuming we are not calling
any relevant functions.
I did try building my own libc using --enable-static-nss but it does not
seem to have built static versions of libnss*. Will look more into it
and try linking kexec with this new glibc and see if that works.
Also tried playing with klibc and uclibc a bit but can't get anything
going quickly.
Thanks
Vivek
Vivek Goyal <[email protected]> writes:
> On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <[email protected]> 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 call routines which trigger nss switch but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just code
>> > inspection.
>>
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used. Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
> I installed glibc-static and built kexec-tools using gcc "-static" option.
> It built just fine and infact kdump is working with it.
>
> Size of new kexec binary is around 1.4MB.
>
> Did not get any warning w.r.t nss, so I am assuming we are not calling
> any relevant functions.
>
> I did try building my own libc using --enable-static-nss but it does not
> seem to have built static versions of libnss*. Will look more into it
> and try linking kexec with this new glibc and see if that works.
>
> Also tried playing with klibc and uclibc a bit but can't get anything
> going quickly.
Sounds good. It has been about a year since I looked but kexec built
uclibc just fine last time I tried it.
Eric
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 killed
and if sombody is trying to execute a malformed exceptionally large
executable, system will start killing other processess. We can potentially
lock all the memory in kernel just by trying to execute a signed huge
executable. Not good.
I was looking at IMA and they seem to be using kernel_read() for reading
page in and update digest. IIUC, that means page is read from disk,
brought in cache and if needed will be read back from disk. But that
means hacker can try to do some timing tricks and try to replace disk image
after signature verification and run unsigned program.
So how do we go about it. Neither of the approaches sound appealing
to me.
Thanks
Vivek
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 memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
>
Also, even if we try to read in whole executable, can't an hacker modify
pages in swap disk and then they will be faulted back in and bingo hacker
is running its unsigned code. (assuming root has been compromised otherwise
why do we have to do all this exercise).
Thanks
Vivek
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 memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
>
> I was looking at IMA and they seem to be using kernel_read() for reading
> page in and update digest. IIUC, that means page is read from disk,
> brought in cache and if needed will be read back from disk. But that
> means hacker can try to do some timing tricks and try to replace disk image
> after signature verification and run unsigned program.
For the reason you mentioned, the signature verification is deferred to
bprm, after the executable has been locked from modification. Any
subsequent changes to the file would cause the file to be re-appraised.
The goal of EVM/IMA-appraisal is to detect file tampering and enforce
file data/metadata integrity. If EVM/IMA-appraisal fail, then as a last
resort, we fall back and rely on IMA measurement/attestation at least to
detect it.
Mimi
> So how do we go about it. Neither of the approaches sound appealing
> to me.
>
> Thanks
> Vivek
Vivek Goyal <[email protected]> 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 will have to read the whole executable
>> in memory. That sounds bad as we are in kernel mode and will not be killed
>> and if sombody is trying to execute a malformed exceptionally large
>> executable, system will start killing other processess. We can potentially
>> lock all the memory in kernel just by trying to execute a signed huge
>> executable. Not good.
>>
>
> Also, even if we try to read in whole executable, can't an hacker modify
> pages in swap disk and then they will be faulted back in and bingo hacker
> is running its unsigned code. (assuming root has been compromised otherwise
> why do we have to do all this exercise).
You make a decent case for an implicit mlockall(MCL_FUTURE) being
required of signed executables, that are going to be granted privileges
based on signature verification.
As for size if the executable won't fit in memory, there is no point in
checking the signature.
It should be fairly straight forward to make the signature checking
process preemptable and killable.
Of course this is all hand waving at this point.
Eric
On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> 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 will have to read the whole executable
> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> and if sombody is trying to execute a malformed exceptionally large
> >> executable, system will start killing other processess. We can potentially
> >> lock all the memory in kernel just by trying to execute a signed huge
> >> executable. Not good.
> >>
> >
> > Also, even if we try to read in whole executable, can't an hacker modify
> > pages in swap disk and then they will be faulted back in and bingo hacker
> > is running its unsigned code. (assuming root has been compromised otherwise
> > why do we have to do all this exercise).
>
> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> required of signed executables, that are going to be granted privileges
> based on signature verification.
implicity lockall for signed executables sounds reasonable to avoid the
swap hack.
>
> As for size if the executable won't fit in memory, there is no point in
> checking the signature.
Well I am worried about malformed executables. One can sign a huge
executable (which is never meant to run successfully) and cause all
kind of memory issues.
Can we first look at the signature, decrypt it using certificates in
kernel ring, and if we find out that executable was signed by any
of the certificates, only then we go on to read in whole executable
and try to calculate the digest. May be at the time of signing we can put
a string, say "LINUX", along with digest and then sing/encrypt it. Upon
decryption we can check if LINUX is there and if yes, we know it was
signed by the certifcate loaded in kernel and then go on to load the
full executable and calculate digest.
Not sure if above is doable or not but if it is, it might reduce the
risk significantly as we will not try to integrity verify executables
not signed by genuine certificates.
>
> It should be fairly straight forward to make the signature checking
> process preemptable and killable.
hmm..., not sure how to do this. Will have to read more code to understand
process killing and see what can I do this while I am in kernel mode
and I possibly might have done kernel memory allocations using
vmalloc()/kmalloc() etc.
Thanks
Vivek
Vivek Goyal <[email protected]> writes:
> On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <[email protected]> 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 will have to read the whole executable
>> >> in memory. That sounds bad as we are in kernel mode and will not be killed
>> >> and if sombody is trying to execute a malformed exceptionally large
>> >> executable, system will start killing other processess. We can potentially
>> >> lock all the memory in kernel just by trying to execute a signed huge
>> >> executable. Not good.
>> >>
>> >
>> > Also, even if we try to read in whole executable, can't an hacker modify
>> > pages in swap disk and then they will be faulted back in and bingo hacker
>> > is running its unsigned code. (assuming root has been compromised otherwise
>> > why do we have to do all this exercise).
>>
>> You make a decent case for an implicit mlockall(MCL_FUTURE) being
>> required of signed executables, that are going to be granted privileges
>> based on signature verification.
>
> implicity lockall for signed executables sounds reasonable to avoid the
> swap hack.
>
>>
>> As for size if the executable won't fit in memory, there is no point in
>> checking the signature.
>
> Well I am worried about malformed executables. One can sign a huge
> executable (which is never meant to run successfully) and cause all
> kind of memory issues.
Good point what to do with executables with invalid sigantures. From
another reply it sounded like one of the bits of IMA/EVM had already
addressed part of that.
> Can we first look at the signature, decrypt it using certificates in
> kernel ring, and if we find out that executable was signed by any
> of the certificates, only then we go on to read in whole executable
> and try to calculate the digest. May be at the time of signing we can put
> a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> decryption we can check if LINUX is there and if yes, we know it was
> signed by the certifcate loaded in kernel and then go on to load the
> full executable and calculate digest.
> Not sure if above is doable or not but if it is, it might reduce the
> risk significantly as we will not try to integrity verify executables
> not signed by genuine certificates.
Known plaintext in the signed blob should allow that. I would be very
careful with that because it sounds like the kind of thing that opens
you up to plain-text attacks, but that is mostly my parania and lack of
experience speaking.
>> It should be fairly straight forward to make the signature checking
>> process preemptable and killable.
>
> hmm..., not sure how to do this. Will have to read more code to understand
> process killing and see what can I do this while I am in kernel mode
> and I possibly might have done kernel memory allocations using
> vmalloc()/kmalloc() etc.
Well basically it is matter of using the killable version of waits
returning an error code as you unwind, and eventually either
force_sig(SIGKILL) or do_exit().
There are a lot of times where you can support SIGKILL and just cause
the process to exit where you can't handle signals.
Eric
On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote:
> Vivek Goyal <[email protected]> writes:
>
> > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> >> Vivek Goyal <[email protected]> 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 will have to read the whole executable
> >> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> >> and if sombody is trying to execute a malformed exceptionally large
> >> >> executable, system will start killing other processess. We can potentially
> >> >> lock all the memory in kernel just by trying to execute a signed huge
> >> >> executable. Not good.
> >> >>
> >> >
> >> > Also, even if we try to read in whole executable, can't an hacker modify
> >> > pages in swap disk and then they will be faulted back in and bingo hacker
> >> > is running its unsigned code. (assuming root has been compromised otherwise
> >> > why do we have to do all this exercise).
> >>
> >> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> >> required of signed executables, that are going to be granted privileges
> >> based on signature verification.
> >
> > implicity lockall for signed executables sounds reasonable to avoid the
> > swap hack.
> >
> >>
> >> As for size if the executable won't fit in memory, there is no point in
> >> checking the signature.
> >
> > Well I am worried about malformed executables. One can sign a huge
> > executable (which is never meant to run successfully) and cause all
> > kind of memory issues.
>
> Good point what to do with executables with invalid sigantures. From
> another reply it sounded like one of the bits of IMA/EVM had already
> addressed part of that.
With IMA-appraisal enabled (enforcing mode), it would not be executed.
> > Can we first look at the signature, decrypt it using certificates in
> > kernel ring, and if we find out that executable was signed by any
> > of the certificates, only then we go on to read in whole executable
> > and try to calculate the digest. May be at the time of signing we can put
> > a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> > decryption we can check if LINUX is there and if yes, we know it was
> > signed by the certifcate loaded in kernel and then go on to load the
> > full executable and calculate digest.
>
> > Not sure if above is doable or not but if it is, it might reduce the
> > risk significantly as we will not try to integrity verify executables
> > not signed by genuine certificates.
>
> Known plaintext in the signed blob should allow that. I would be very
> careful with that because it sounds like the kind of thing that opens
> you up to plain-text attacks, but that is mostly my parania and lack of
> experience speaking.
Although IMA (measurement and attestation), IMA-appraisal (local
integrity enforcement), and IMA auditing (logging hashes) can be enabled
individually, if any of these functions are enabled, then assuming the
file is in the IMA policy, the file will be hashed. Remember if all
else fails, measurement and attestation is your last line of defense,
for detecting if your system has been compromised.
Mimi
> >> It should be fairly straight forward to make the signature checking
> >> process preemptable and killable.
> >
> > hmm..., not sure how to do this. Will have to read more code to understand
> > process killing and see what can I do this while I am in kernel mode
> > and I possibly might have done kernel memory allocations using
> > vmalloc()/kmalloc() etc.
>
> Well basically it is matter of using the killable version of waits
> returning an error code as you unwind, and eventually either
> force_sig(SIGKILL) or do_exit().
>
> There are a lot of times where you can support SIGKILL and just cause
> the process to exit where you can't handle signals.
>
>
> Eric
>