Re: Trusted kernel patchset for Secure Boot lockdown
> Whether Microsoft would actually follow through on blacklisting their > own signatures is obviously an unknown - they've told us they would, but > commercial concerns etc who knows. They *will* blacklist our signatures. I think that becomes an irrelevant debate. It's going to end up being argued in a court by lawyers some day and its not software problem. One day some bright spark from MS will decide to do things like enforce patent disputes this way or commercial pressures will lead them to try and find some other excuse to do it. It's never going to be "secure", so they'll always be able to find an excuse. The functionality you have to disable is for the most part quite boring for desktop users. Server may see it differently because you cripple a lot of debugging work. OTOH many of them probably want to turn it on for production boxes. The main thing you lose are lots of module options, the ability to force addresses for things like the serial port console (otherwise I can force an address and root the kernel that way), mem=, custom ACPI tables and so on. It's the stuff that lets you get a box with crapware as firmware working that's really hit. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-20 at 10:55 -0400, ty...@mit.edu wrote: > I disagree; it's highly likely, if not certain that Windows booting > under UEFI secure boot is going to be able to do some of the things > that people are proposing that we have to prohibit in the name of > security. That's because presumably Windows won't be willing to make > certain usability tradeoffs, and since they control the signing certs, > even in the unlikely case that people can leverage these "holes" to > enable a boot sector virus, it seems unlikely that Windows will revoke > its own cert. I don't think any of the functionality we're disabling (with the arguable exception of kexec, which, again, there is a plan to handle) is useful on modern systems. And, seriously, if this forces vendors to write actual kernel drivers rather than run an io port banging IPMI driver in userspace, that's a *good* thing. Whether Microsoft would actually follow through on blacklisting their own signatures is obviously an unknown - they've told us they would, but commercial concerns etc who knows. They *will* blacklist our signatures. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Mar 19, 2014 at 01:16:15PM -0700, Kees Cook wrote: > UEFI is a red herring in both cases. This isn't about UEFI, it just > happens that one of the things that can assert "trusted_kernel" is the > UEFI Secure Boot path. Chrome OS would assert "trusted_kernel" by > passing it on the kernel command line (since it, along with firmware, > kernel, and root fs are effectively measured). A > boot-my-router-from-CD system can assert similarly because the kernel > is on RO media. I disagree; it's highly likely, if not certain that Windows booting under UEFI secure boot is going to be able to do some of the things that people are proposing that we have to prohibit in the name of security. That's because presumably Windows won't be willing to make certain usability tradeoffs, and since they control the signing certs, even in the unlikely case that people can leverage these "holes" to enable a boot sector virus, it seems unlikely that Windows will revoke its own cert. The security goals for Windows' secure boot is quite a bit weaker than what ChromeOS is trying to promise; this is why I claim the real argument is over what the goals are for "trusted boot". Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
> Capabilities can be seen as related to this patch set, but it cannot > be seen as a blocker. This logic is needed today, it's implemented, > and it clearly marks where the known problems are. If an overhaul of > capabilities happens, it can happen separately. A working version is needed today - but the implementation assumes things like the idea you can blacklist a few boot parameters and all is good. The reality is the reverse. So this at the moment is security theatre at least for the EFI and PC case. At the minimum you need to do module and kernel command line parameter whitelisting/signing. It's also rather odd to suggest the solution is to splatter changes all over the kernel causing mass churn and maintainer headache... so that we can do the whole mass churn again fixing what was added. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
Capabilities can be seen as related to this patch set, but it cannot be seen as a blocker. This logic is needed today, it's implemented, and it clearly marks where the known problems are. If an overhaul of capabilities happens, it can happen separately. A working version is needed today - but the implementation assumes things like the idea you can blacklist a few boot parameters and all is good. The reality is the reverse. So this at the moment is security theatre at least for the EFI and PC case. At the minimum you need to do module and kernel command line parameter whitelisting/signing. It's also rather odd to suggest the solution is to splatter changes all over the kernel causing mass churn and maintainer headache... so that we can do the whole mass churn again fixing what was added. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Mar 19, 2014 at 01:16:15PM -0700, Kees Cook wrote: UEFI is a red herring in both cases. This isn't about UEFI, it just happens that one of the things that can assert trusted_kernel is the UEFI Secure Boot path. Chrome OS would assert trusted_kernel by passing it on the kernel command line (since it, along with firmware, kernel, and root fs are effectively measured). A boot-my-router-from-CD system can assert similarly because the kernel is on RO media. I disagree; it's highly likely, if not certain that Windows booting under UEFI secure boot is going to be able to do some of the things that people are proposing that we have to prohibit in the name of security. That's because presumably Windows won't be willing to make certain usability tradeoffs, and since they control the signing certs, even in the unlikely case that people can leverage these holes to enable a boot sector virus, it seems unlikely that Windows will revoke its own cert. The security goals for Windows' secure boot is quite a bit weaker than what ChromeOS is trying to promise; this is why I claim the real argument is over what the goals are for trusted boot. Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-20 at 10:55 -0400, ty...@mit.edu wrote: I disagree; it's highly likely, if not certain that Windows booting under UEFI secure boot is going to be able to do some of the things that people are proposing that we have to prohibit in the name of security. That's because presumably Windows won't be willing to make certain usability tradeoffs, and since they control the signing certs, even in the unlikely case that people can leverage these holes to enable a boot sector virus, it seems unlikely that Windows will revoke its own cert. I don't think any of the functionality we're disabling (with the arguable exception of kexec, which, again, there is a plan to handle) is useful on modern systems. And, seriously, if this forces vendors to write actual kernel drivers rather than run an io port banging IPMI driver in userspace, that's a *good* thing. Whether Microsoft would actually follow through on blacklisting their own signatures is obviously an unknown - they've told us they would, but commercial concerns etc who knows. They *will* blacklist our signatures. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
Whether Microsoft would actually follow through on blacklisting their own signatures is obviously an unknown - they've told us they would, but commercial concerns etc who knows. They *will* blacklist our signatures. I think that becomes an irrelevant debate. It's going to end up being argued in a court by lawyers some day and its not software problem. One day some bright spark from MS will decide to do things like enforce patent disputes this way or commercial pressures will lead them to try and find some other excuse to do it. It's never going to be secure, so they'll always be able to find an excuse. The functionality you have to disable is for the most part quite boring for desktop users. Server may see it differently because you cripple a lot of debugging work. OTOH many of them probably want to turn it on for production boxes. The main thing you lose are lots of module options, the ability to force addresses for things like the serial port console (otherwise I can force an address and root the kernel that way), mem=, custom ACPI tables and so on. It's the stuff that lets you get a box with crapware as firmware working that's really hit. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 4:18 PM, Theodore Ts'o wrote: > On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote: >> > Signed userspace is not a requirement, and therefore any solution that >> > relies on a signed initrd is inadequate. There are use cases that >> > require verification of the initrd and other levels. This isn't one of >> > them. >> >> The job of the kernel is to solve the general problem. There are lots of >> people who happen to care about verification beyond the kernel so it >> shouldn't be ignored. And they can do do things like load trusted SELinux >> rulesets even if you can't support it in your environment. > > This is really a question about goals and trust models. Alan is > arguing that we should support trust models and goals which go far > beyond the goals and trust model of the UEFI Forum. > > Matthew is, I think, trying to make the argument that his patches > fulfill the goals that are needed so we can boot Linux distribution > kernels on UEFI secure boot machines without worrying about Microsoft > deciding to revoke keys so that Red Hat or SuSE will no longer be able > to be bootable on desktops that are certified for Windows 8. And > while we might want to improve the framework to support other trust > models later on, supporting distro kernels on Windows 8 certified PC's > is important enough that we should let these patches into mainline. > > Is that a fair summary of the two viewpoints? UEFI is a red herring in both cases. This isn't about UEFI, it just happens that one of the things that can assert "trusted_kernel" is the UEFI Secure Boot path. Chrome OS would assert "trusted_kernel" by passing it on the kernel command line (since it, along with firmware, kernel, and root fs are effectively measured). A boot-my-router-from-CD system can assert similarly because the kernel is on RO media. Based on my view of the conversation, it's about whether or not capable() can be made to do these checks. The proposal about creating the action/privilege map is interesting, and I'm all for doing it just to make things easy to reason about for capabilities, but it still seems separate from this work. There still needs to be a global boolean for the "trusted kernel" state. It would be used, for example, on the module param whitelisting, which has nothing to do with capabilities. It would be used to change driver behavior (e.g. disabling DMA or other badness that isn't trusted), which has nothing to do with capabilities. The ability to check this state is going to be needed going into the future as we uncover more dangerous interfaces. Since the capability work is separate, when it happens, that same regex work could replace some of the is_trusted_kernel checks with new action tests, but we still need the same infrastructure and identification of dangerous interfaces. Capabilities can be seen as related to this patch set, but it cannot be seen as a blocker. This logic is needed today, it's implemented, and it clearly marks where the known problems are. If an overhaul of capabilities happens, it can happen separately. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 3:31 PM, One Thousand Gnomes wrote: > On Fri, 14 Mar 2014 22:15:45 + > Matthew Garrett wrote: > >> On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: >> > On Fri, 14 Mar 2014 21:56:33 + >> > Matthew Garrett wrote: >> > > Signed userspace is not a requirement, and therefore any solution that >> > > relies on a signed initrd is inadequate. There are use cases that >> > > require verification of the initrd and other levels. This isn't one of >> > > them. >> > >> > The job of the kernel is to solve the general problem. There are lots of >> > people who happen to care about verification beyond the kernel so it >> > shouldn't be ignored. And they can do do things like load trusted SELinux >> > rulesets even if you can't support it in your environment. >> >> The general problem includes having to support this even without an >> selinux policy. > > Yes. No dispute about that. But equally the general solution should allow > for it. > >> And one that's not going to change, so the general problem includes not >> relying on a signed initramfs. > > Likewise > >> some other way. ChromeOS will load unmeasured kernel modules provided it >> can attest to the trustworthyness of the filesystem containing them. > > See "How to Bypass Verified Boot Security in Chromium OS" 8) That method a) is intentionally available (system owner can disable firmware RO and install their own keys), and b) requires physical presence. > So ChromeOS loads *measured* kernel modules. It just did the measuring > differently to the signed module code. Right, using dm-verity. However, the read-only media case is still valid (and is why I am still trying to get the module restrictions LSM accepted, and why I'm modelling my firmware restrictions on the same principle). -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
* One Thousand Gnomes: >> For the Chrome OS use-case, it might be better described as "untrusted >> userspace", but that seems unfriendly. :) The "trusted kernel" name >> seems fine to me. > > Trusted is rather misleading. It's not trusted, it's *measured*. I don't think anyone is doing any measurement. In particular, the kernel does not know anything about the history of the boot process and cannot provide any form of attestation. This is why this feature is not very useful to end users. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
* Theodore Ts'o: > Right now, even though Lenovo laptops are shipping with Windows > 8. UEFI secure boot is not made mandatory (although it is on enough to > brick the laptop when it runs into bugs wwith the UEFI BIOS code, > sigh). But sooner or later, UEFI secure boot will be on by default, > and then if Linux distros don't have kernels where the installer can > be run without needing to twiddle BIOS settings, it might make it > harder for the "Year of the Desktop" to come about. Windows 8 logo devices already enable Secure Boot by default. One aspect which makes all this really tricky is that Microsoft is watching what we're doing and will keep raising the bar, probably not with the intent to lock us out completely, but sufficiently high to make things quite annoying. For example, any certificate-signing certificate in the boot process needs to be an EV CA certificate, which comes with fairly stringent requirements that are quite costly to implement. So any restrictions we implement as a good-will gesture will eventually come back to haunt us. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
* Theodore Ts'o: Right now, even though Lenovo laptops are shipping with Windows 8. UEFI secure boot is not made mandatory (although it is on enough to brick the laptop when it runs into bugs wwith the UEFI BIOS code, sigh). But sooner or later, UEFI secure boot will be on by default, and then if Linux distros don't have kernels where the installer can be run without needing to twiddle BIOS settings, it might make it harder for the Year of the Desktop to come about. Windows 8 logo devices already enable Secure Boot by default. One aspect which makes all this really tricky is that Microsoft is watching what we're doing and will keep raising the bar, probably not with the intent to lock us out completely, but sufficiently high to make things quite annoying. For example, any certificate-signing certificate in the boot process needs to be an EV CA certificate, which comes with fairly stringent requirements that are quite costly to implement. So any restrictions we implement as a good-will gesture will eventually come back to haunt us. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
* One Thousand Gnomes: For the Chrome OS use-case, it might be better described as untrusted userspace, but that seems unfriendly. :) The trusted kernel name seems fine to me. Trusted is rather misleading. It's not trusted, it's *measured*. I don't think anyone is doing any measurement. In particular, the kernel does not know anything about the history of the boot process and cannot provide any form of attestation. This is why this feature is not very useful to end users. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 3:31 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: On Fri, 14 Mar 2014 22:15:45 + Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: On Fri, 14 Mar 2014 21:56:33 + Matthew Garrett matthew.garr...@nebula.com wrote: Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. The general problem includes having to support this even without an selinux policy. Yes. No dispute about that. But equally the general solution should allow for it. And one that's not going to change, so the general problem includes not relying on a signed initramfs. Likewise some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. See How to Bypass Verified Boot Security in Chromium OS 8) That method a) is intentionally available (system owner can disable firmware RO and install their own keys), and b) requires physical presence. So ChromeOS loads *measured* kernel modules. It just did the measuring differently to the signed module code. Right, using dm-verity. However, the read-only media case is still valid (and is why I am still trying to get the module restrictions LSM accepted, and why I'm modelling my firmware restrictions on the same principle). -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 4:18 PM, Theodore Ts'o ty...@mit.edu wrote: On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote: Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. This is really a question about goals and trust models. Alan is arguing that we should support trust models and goals which go far beyond the goals and trust model of the UEFI Forum. Matthew is, I think, trying to make the argument that his patches fulfill the goals that are needed so we can boot Linux distribution kernels on UEFI secure boot machines without worrying about Microsoft deciding to revoke keys so that Red Hat or SuSE will no longer be able to be bootable on desktops that are certified for Windows 8. And while we might want to improve the framework to support other trust models later on, supporting distro kernels on Windows 8 certified PC's is important enough that we should let these patches into mainline. Is that a fair summary of the two viewpoints? UEFI is a red herring in both cases. This isn't about UEFI, it just happens that one of the things that can assert trusted_kernel is the UEFI Secure Boot path. Chrome OS would assert trusted_kernel by passing it on the kernel command line (since it, along with firmware, kernel, and root fs are effectively measured). A boot-my-router-from-CD system can assert similarly because the kernel is on RO media. Based on my view of the conversation, it's about whether or not capable() can be made to do these checks. The proposal about creating the action/privilege map is interesting, and I'm all for doing it just to make things easy to reason about for capabilities, but it still seems separate from this work. There still needs to be a global boolean for the trusted kernel state. It would be used, for example, on the module param whitelisting, which has nothing to do with capabilities. It would be used to change driver behavior (e.g. disabling DMA or other badness that isn't trusted), which has nothing to do with capabilities. The ability to check this state is going to be needed going into the future as we uncover more dangerous interfaces. Since the capability work is separate, when it happens, that same regex work could replace some of the is_trusted_kernel checks with new action tests, but we still need the same infrastructure and identification of dangerous interfaces. Capabilities can be seen as related to this patch set, but it cannot be seen as a blocker. This logic is needed today, it's implemented, and it clearly marks where the known problems are. If an overhaul of capabilities happens, it can happen separately. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
> So as far as the narrow question of whether we should accept these > patches, I think it's a good thing. Personally, I'm always going to > be disabling UEFI secure boot (even if it doesn't brick my laptop), > because for me, the security guarantees it provides isn't worth it. > But there will be people who want to be able to install Linux on > Windows 8 certified PC's without tweaking BIOS settings, so merging > the UEFI secure boot is a good thing, so long as those of use who > don't want to have anything to do with UEFI secure boot can disable > it. I definitely think we want the feature and there are a lot of non UEFI reasons for this (eg running trusted_kernel() virtual namespaces). I have three specific issues 1. The implementation is a mess in part because it propogates more policy all over the place that should be separated. Root cause capable() mixes policy and activity. Fix suggested in my previous emails (and offer to do the work) 2. It's likely to lead to more bugs and errors because of the way it has been done and it doesn't break old code that gets added without considering the issue. It fails insecure which is bad. Fixed by doing what I suggested (and offered to do) 3. For things like module options we should be white not blacklisting 'bad' ones. I've offered to go and fix up the capability stuff - I'm just waiting for Matthew to actually confirm the question I specifically asked him - does this solve that bit of his problem. If it does great, I'll go and sort the capability bits out so we can keep the policy in the right place and we don't have the kernel festooned with && !trusted_kernel() everywhere. There is a question of completeness but its very clear we get there with a combination of two things - whitelisting so we catch stuff we missed rather than leave holes, and just accepting the reality that it'll take a few kernels once its upstream until we get them all. I care about security, we should do the job properly. We have a further magnitude shift in security needs coming that's going to be at least equivalent to the scale of shift between the old 'university, everyone is nice' internet and today. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote: > > Signed userspace is not a requirement, and therefore any solution that > > relies on a signed initrd is inadequate. There are use cases that > > require verification of the initrd and other levels. This isn't one of > > them. > > The job of the kernel is to solve the general problem. There are lots of > people who happen to care about verification beyond the kernel so it > shouldn't be ignored. And they can do do things like load trusted SELinux > rulesets even if you can't support it in your environment. This is really a question about goals and trust models. Alan is arguing that we should support trust models and goals which go far beyond the goals and trust model of the UEFI Forum. Matthew is, I think, trying to make the argument that his patches fulfill the goals that are needed so we can boot Linux distribution kernels on UEFI secure boot machines without worrying about Microsoft deciding to revoke keys so that Red Hat or SuSE will no longer be able to be bootable on desktops that are certified for Windows 8. And while we might want to improve the framework to support other trust models later on, supporting distro kernels on Windows 8 certified PC's is important enough that we should let these patches into mainline. Is that a fair summary of the two viewpoints? Personally, I think that we are fortunate that Windows 8 has been enough of a train wreck that huge numbers of users have been taking Windows 8 systems and upgrading them to Windows 7, and hence the need for Distro kernels that can boot on fully locked down Windows 8 PC's. But at some point, whether it is a few years or a decade later (if Windows 7 lives on as long as XP :-), Windows 7 will be EOL'ed, and even before that, UEFI secure boot will be enabled by default. Right now, even though Lenovo laptops are shipping with Windows 8. UEFI secure boot is not made mandatory (although it is on enough to brick the laptop when it runs into bugs wwith the UEFI BIOS code, sigh). But sooner or later, UEFI secure boot will be on by default, and then if Linux distros don't have kernels where the installer can be run without needing to twiddle BIOS settings, it might make it harder for the "Year of the Desktop" to come about. So as far as the narrow question of whether we should accept these patches, I think it's a good thing. Personally, I'm always going to be disabling UEFI secure boot (even if it doesn't brick my laptop), because for me, the security guarantees it provides isn't worth it. But there will be people who want to be able to install Linux on Windows 8 certified PC's without tweaking BIOS settings, so merging the UEFI secure boot is a good thing, so long as those of use who don't want to have anything to do with UEFI secure boot can disable it. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 22:31 +, One Thousand Gnomes wrote: > On Fri, 14 Mar 2014 22:15:45 + > Matthew Garrett wrote: > > The general problem includes having to support this even without an > > selinux policy. > > Yes. No dispute about that. But equally the general solution should allow > for it. Well, sure. The current implementation doesn't conflict with selinux in any way. > > some other way. ChromeOS will load unmeasured kernel modules provided it > > can attest to the trustworthyness of the filesystem containing them. > > See "How to Bypass Verified Boot Security in Chromium OS" 8) > > And it attests the trustworthiness of the filesystem by measuring it. If > you have a measurement of object X that states it is unchanged then you > have a valid measurement of any subset of object X for which the same > assertion is proven. In this case since you know all the bits in the root > fs are as before, so you know all the bits in the module are as before You may attest to the trustworthiness of a filesystem by measuring it, but you may also attest to it via some other means - for instance, it's read-only and stored on media that requires physical presence to modify. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 22:15:45 + Matthew Garrett wrote: > On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: > > On Fri, 14 Mar 2014 21:56:33 + > > Matthew Garrett wrote: > > > Signed userspace is not a requirement, and therefore any solution that > > > relies on a signed initrd is inadequate. There are use cases that > > > require verification of the initrd and other levels. This isn't one of > > > them. > > > > The job of the kernel is to solve the general problem. There are lots of > > people who happen to care about verification beyond the kernel so it > > shouldn't be ignored. And they can do do things like load trusted SELinux > > rulesets even if you can't support it in your environment. > > The general problem includes having to support this even without an > selinux policy. Yes. No dispute about that. But equally the general solution should allow for it. > And one that's not going to change, so the general problem includes not > relying on a signed initramfs. Likewise > some other way. ChromeOS will load unmeasured kernel modules provided it > can attest to the trustworthyness of the filesystem containing them. See "How to Bypass Verified Boot Security in Chromium OS" 8) And it attests the trustworthiness of the filesystem by measuring it. If you have a measurement of object X that states it is unchanged then you have a valid measurement of any subset of object X for which the same assertion is proven. In this case since you know all the bits in the root fs are as before, so you know all the bits in the module are as before And how do you know all the bits in the root fs are as before, because you have a set of measurements (hashes) on partition 12. At the end of the day you end up with a chain of measurements from a trusted thing you deep immutable. If your chain has gaps you have holes (see above). So ChromeOS loads *measured* kernel modules. It just did the measuring differently to the signed module code. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: > On Fri, 14 Mar 2014 21:56:33 + > Matthew Garrett wrote: > > Signed userspace is not a requirement, and therefore any solution that > > relies on a signed initrd is inadequate. There are use cases that > > require verification of the initrd and other levels. This isn't one of > > them. > > The job of the kernel is to solve the general problem. There are lots of > people who happen to care about verification beyond the kernel so it > shouldn't be ignored. And they can do do things like load trusted SELinux > rulesets even if you can't support it in your environment. The general problem includes having to support this even without an selinux policy. > > > Even in EFI you can make your kernel or loader check the initrd signature > > > and the rootfs signature if you want. > > > > Except the initramfs gets built at kernel install time. > > Implementation detail for your use case. And one that's not going to change, so the general problem includes not relying on a signed initramfs. > > > Correct me if I am wrong but your starting point is "I have a chain of > > > measurement as far as the kernel I load". Without that I can just go into > > > grub and 0wn you. > > > > In my use case. But not all implementations will be measuring things - > > they can assert that the kernel is trustworthy through some other > > mechanism. This genuinely is about trust, not measurement. > > The assertion you attempt to achieve is I believe > > "No ring 0 code is executed directly or indirectly that is not measured" No. As I keep pointing out, not all code is measured. The firmware is not required to measure itself. A particular implementation may skip measuring the kernel because it can attest to its trustworthyness in some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 21:56:33 + Matthew Garrett wrote: > On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote: > > > In your particularly implementation maybe you've got a weak setup where > > you don't measure down to your initrd. That's a *flaw* in your > > implementation. Don't inflict your limitations on others or on the > > future. EFI is only one (and not a very strong one at that) implementation > > of a 'secure' boot chain. A lot of other systems can not only propogate > > measurement and security assertions into their initrd they can propogate > > them into their rootfs (yes upgrades are .. exciting, but these kinds of > > users will live with that pain). > > Signed userspace is not a requirement, and therefore any solution that > relies on a signed initrd is inadequate. There are use cases that > require verification of the initrd and other levels. This isn't one of > them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. > > Even in EFI you can make your kernel or loader check the initrd signature > > and the rootfs signature if you want. > > Except the initramfs gets built at kernel install time. Implementation detail for your use case. > > Correct me if I am wrong but your starting point is "I have a chain of > > measurement as far as the kernel I load". Without that I can just go into > > grub and 0wn you. > > In my use case. But not all implementations will be measuring things - > they can assert that the kernel is trustworthy through some other > mechanism. This genuinely is about trust, not measurement. The assertion you attempt to achieve is I believe "No ring 0 code is executed directly or indirectly that is not measured" Some of your measuring is EFI boot, some is module signing and then you must impose a security model as well. It's a "measurement" problem if you ask what the rule is - yes ? Getting there is not just a measurement problem but your intended result is a measurement based rule ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 21:58 +, One Thousand Gnomes wrote: > On Fri, 14 Mar 2014 19:24:55 + > Matthew Garrett wrote: > > As an example, imagine a platform with the bootloader and kernel on > > read-only media. The platform can assert that the kernel is trusted even > > if there's no measurement of the kernel. > > Only if you have a secure signed path through the controller firmware and > physical security of the hardware. If not I can reprogram your BIOS, your > GPU firmware, your USB stick or your CD-ROM controller to lie. Sure, and then the trust that the firmware placed in the kernel would be misplaced. You can subvert Secure Boot with an SPI flasher, just as you can subvert selinux with a firewire dongle. Those attacks are outside the threat model. If you're in a situation where you have to care about threats outside that threat model then you need to choose a more appropriate solution. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 19:24:55 + Matthew Garrett wrote: > On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote: > > > The fact that you keep saying measured really does make me suspect that > > you misunderstand the problem. There's no measurement involved, there's > > simply an assertion that the firmware (which you're forced to trust) > > chose, via some policy you may be unaware of, to trust the booted > > kernel. > > As an example, imagine a platform with the bootloader and kernel on > read-only media. The platform can assert that the kernel is trusted even > if there's no measurement of the kernel. Only if you have a secure signed path through the controller firmware and physical security of the hardware. If not I can reprogram your BIOS, your GPU firmware, your USB stick or your CD-ROM controller to lie. Anything must either be measurable or tamperproof from within the system itself (or both). So a physically write protected ROM bootloader loading a kernel and initrd from that same physically protected ROM is secure, but your average CD-ROM drive is not. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote:
> In your particularly implementation maybe you've got a weak setup where
> you don't measure down to your initrd. That's a *flaw* in your
> implementation. Don't inflict your limitations on others or on the
> future. EFI is only one (and not a very strong one at that) implementation
> of a 'secure' boot chain. A lot of other systems can not only propogate
> measurement and security assertions into their initrd they can propogate
> them into their rootfs (yes upgrades are .. exciting, but these kinds of
> users will live with that pain).
Signed userspace is not a requirement, and therefore any solution that
relies on a signed initrd is inadequate. There are use cases that
require verification of the initrd and other levels. This isn't one of
them.
> Even in EFI you can make your kernel or loader check the initrd signature
> and the rootfs signature if you want.
Except the initramfs gets built at kernel install time.
> > The fact that you keep saying measured really does make me suspect that
> > you misunderstand the problem. There's no measurement involved, there's
> > simply an assertion that the firmware (which you're forced to trust)
> > chose, via some policy you may be unaware of, to trust the booted
> > kernel.
>
> You are currently using some of those interfaces for measuring to produce
> a notionally 'trusted' initial loaded environment.
>
> Correct me if I am wrong but your starting point is "I have a chain of
> measurement as far as the kernel I load". Without that I can just go into
> grub and 0wn you.
In my use case. But not all implementations will be measuring things -
they can assert that the kernel is trustworthy through some other
mechanism. This genuinely is about trust, not measurement.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
> I have a set of patches that appear acceptable to the security > maintainer. I've rewritten them multiple times in response to various > levels of bikeshedding. They solve a real problem and are being shipped > by multiple distributions. And ? I've seen some of the other "extra" stuff distributions ship. Lots of it is hilariously bad. That really isn't a good argument for the code - for the feature yes. > What the rest of your mail is asking me to do is to rewrite capabilities > support entirely. Now, yes, I agree that capabilities are an awful > interface that's approximately impossible to use correctly and which > adds little security even if you do. But I reject the idea that > rewriting fundamental security infrastructure should be a prerequisite > for adding this functionality. Actually it's nothing of the sort. It's a proposal to do it. It's 90% a regexp task. I'm offering to go and do that bit. I am quite happy to do the capability crapfest fixing. It wants doing *anyway*. But if I got do that work, does it solve your problem ? I think it does but I'd like to be sure. > > > It needs to be possible for this policy to be imposed without userspace > > > being involved, so using selinux would mean baking it into the kernel > > > (along with an additional implementation for apparmor, and presumably > > > one for tomoyo as well). > > > > That's clearly false. You can load signed modules so you can load signed > > policies. Assuming you don't have an initial measured file system you > > need a kernel policy initially that protects you. If you have a measured > > file system you don't even need that, nor do you need to revoke RAWIO in > > kernel, you can do it before you switch into "measured and running > > un-measured code" mode - ie about the point you pivot root out of the > > initrd that loaded the measured policy. > > We can't rely on userspace choosing to load that policy. We don't have a > measured filesystem. The initrd is not signed (and nor can it be). The > kernel itself *must* impose policy. In your particularly implementation maybe you've got a weak setup where you don't measure down to your initrd. That's a *flaw* in your implementation. Don't inflict your limitations on others or on the future. EFI is only one (and not a very strong one at that) implementation of a 'secure' boot chain. A lot of other systems can not only propogate measurement and security assertions into their initrd they can propogate them into their rootfs (yes upgrades are .. exciting, but these kinds of users will live with that pain). Even in EFI you can make your kernel or loader check the initrd signature and the rootfs signature if you want. > Sure! Except then A Large Vendor's custom IPMI userspace stops working, > even on systems without Secure Boot, and then said Large Vendor wants to > have conference calls at times that are convenient for Japan and then > this is an issue that's going to cause $1 billion in lost sales and come > on, you've been there. You know that this isn't going to work. That's not an upstream problem (but with my work hat on I understand your position). Anyway they'll be running someones enterprise product which will have legacy enabled out of the wazoo so their customers 15 year old "we lost the code" blob that nobody can even remember what it does still works 8) > > If we are going to do a measured kernel then it needs to be done right, > > it needs to be properly abstracted so we don't add another one for > > Android, another one for Chrome, another one for ARM trustzone, another > > one for Intel SGX, and so on. > > The fact that you keep saying measured really does make me suspect that > you misunderstand the problem. There's no measurement involved, there's > simply an assertion that the firmware (which you're forced to trust) > chose, via some policy you may be unaware of, to trust the booted > kernel. You are currently using some of those interfaces for measuring to produce a notionally 'trusted' initial loaded environment. Correct me if I am wrong but your starting point is "I have a chain of measurement as far as the kernel I load". Without that I can just go into grub and 0wn you. There are multiple things you want to do in measured environments, stopping people sneakily loading new kernels is one of them. If you want to talk about "secure" that implies a whole load more than ring 0 hacks. It implies having a model where not only has J Random smart hacker gone over the code and hacked all the call points, but that someone has done some kind of formal review of it, used good security practices like whitelisting and thought very hard about the rest of the exposed surfaces. Otherwise its security theatre, it's marketing fluff. We've got lots of marketing security fluff in the kernel, we don't need more of it. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 13:37 -0700, David Lang wrote: > On Fri, 14 Mar 2014, Matthew Garrett wrote: > > As an example, imagine a platform with the bootloader and kernel on > > read-only media. The platform can assert that the kernel is trusted even > > if there's no measurement of the kernel. > > Trusted by who? The platform. If you don't trust the platform's ability to make that decision then that's something that informs your own behaviour, not the platform's. > Alan is saying measured because then if it matches what the owner of that > device > intends it's trusted, but just because you trust it doesn't mean that I trust > it, and it doesn't mean that the russian government should trust it, etc. "Measured" has a specific meaning. If you trust a file based on its source rather than some property of the file itself, you're not measuring it. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014, Matthew Garrett wrote: On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote: The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. As an example, imagine a platform with the bootloader and kernel on read-only media. The platform can assert that the kernel is trusted even if there's no measurement of the kernel. Trusted by who? Alan is saying measured because then if it matches what the owner of that device intends it's trusted, but just because you trust it doesn't mean that I trust it, and it doesn't mean that the russian government should trust it, etc. There just isn't one value of trust. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
> The fact that you keep saying measured really does make me suspect that
> you misunderstand the problem. There's no measurement involved, there's
> simply an assertion that the firmware (which you're forced to trust)
> chose, via some policy you may be unaware of, to trust the booted
> kernel.
As an example, imagine a platform with the bootloader and kernel on
read-only media. The platform can assert that the kernel is trusted even
if there's no measurement of the kernel.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 17:06 +, One Thousand Gnomes wrote: > > But you keep talking about MSRs despite there being a patch that limits > > access to MSRs. If you have specific examples of privilege escalations > > that are possible even with these patches then please, mention them. > > I mentioned MSRs once, and then you kept going on about it. You've twice mentioned MSRs as a case where CAP_SYS_RAWIO allows you to elevate privileges, despite that being a case that's explicitly covered by this patchset. Now, do you have an actual example of CAP_SYS_RAWIO allowing you to elevate privileges even with this patchset applied (and without requiring the presence of obsolete hardware, which is a separate conversation)? > Your patches are all over the tree, for what should be one piece of > policy. They rely on not missing a single case, which is also bad > security engineering. We know that, as an industry we've spent fifty > years repeatedly sticking our fingers in our ears, refusing to listen and > then learning it again and again the hard way. I have a set of patches that appear acceptable to the security maintainer. I've rewritten them multiple times in response to various levels of bikeshedding. They solve a real problem and are being shipped by multiple distributions. What the rest of your mail is asking me to do is to rewrite capabilities support entirely. Now, yes, I agree that capabilities are an awful interface that's approximately impossible to use correctly and which adds little security even if you do. But I reject the idea that rewriting fundamental security infrastructure should be a prerequisite for adding this functionality. > > It needs to be possible for this policy to be imposed without userspace > > being involved, so using selinux would mean baking it into the kernel > > (along with an additional implementation for apparmor, and presumably > > one for tomoyo as well). > > That's clearly false. You can load signed modules so you can load signed > policies. Assuming you don't have an initial measured file system you > need a kernel policy initially that protects you. If you have a measured > file system you don't even need that, nor do you need to revoke RAWIO in > kernel, you can do it before you switch into "measured and running > un-measured code" mode - ie about the point you pivot root out of the > initrd that loaded the measured policy. We can't rely on userspace choosing to load that policy. We don't have a measured filesystem. The initrd is not signed (and nor can it be). The kernel itself *must* impose policy. > > ...thus breaking userspace outside this use case. I mean, sure, I'm > > absolutely fine with deleting /dev/mem entirely. I don't see Linus > > agreeing. > > That's not what I meant. We have a lot of interfaces where we use > CAP_SYS_RAWIO rather than having a structured interface as opposed to a > 'yeah whatever, poke the registers' interface. > > For a lot of environments btw you don't actually need /dev/mem. It's not > really got a lot of uses any more and plenty of people really restrict or > remove it from systems. I don't think very many people would be sad > if /dev/mem became a legacy interface most people left turned off. Sure! Except then A Large Vendor's custom IPMI userspace stops working, even on systems without Secure Boot, and then said Large Vendor wants to have conference calls at times that are convenient for Japan and then this is an issue that's going to cause $1 billion in lost sales and come on, you've been there. You know that this isn't going to work. > If we are going to do a measured kernel then it needs to be done right, > it needs to be properly abstracted so we don't add another one for > Android, another one for Chrome, another one for ARM trustzone, another > one for Intel SGX, and so on. The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
> But you keep talking about MSRs despite there being a patch that limits > access to MSRs. If you have specific examples of privilege escalations > that are possible even with these patches then please, mention them. I mentioned MSRs once, and then you kept going on about it. Your patches are all over the tree, for what should be one piece of policy. They rely on not missing a single case, which is also bad security engineering. We know that, as an industry we've spent fifty years repeatedly sticking our fingers in our ears, refusing to listen and then learning it again and again the hard way. > How is capable() going to be any use when deciding whether or not to > interpret some kernel command line options? I have no idea, why are you asking such an odd question ? You need to whitelist module parameters and boot options that are safe in your measured kernel environment. Nothing to do with RAWIO or capable(), just that we have thousands of such options many of which are quite exploitable because they assume the loader is trustable (which btw is already *broken* and on many systems - eg Fedora - allows you to break from DAC override into RAWIO). That one actually wants cleaning up anyway but its hard to see the right way to do it. > We still need a mechanism to differentiate between cases where > CAP_SYS_RAWIO should be forbidden and cases where it should be > permitted, which means that we need to add additional policy. We can > modify capable(), but that means that capable() no longer does what you > expect it to - it's not a transparent interface, and that's likely to > result in people accidentally misusing it. capable() is not a good interface. If we are going to patch half the capable() calls in the kernel wouldn't it be a good time to actually do something about it properly ? At the very least we should turn capabilities/needs into two lists and make them a 2D grid so we break the tie between the userspace 'capability' and 'what this allows you to do in this specific instance'. For example instead of spewing magic trusted kernel checks all over the place we could do a global seach/replace of most of the capable calls with is_permitted(x) where x is a value indicating what we wish to do (action) not what right we need (policy). All the real mess comes from the fact that capable() is implementing security *policy* in drivers all over the kernel. You can then set up a map of capability to X values, and more importantly you can use that map to have more complete, and descriptive versions of 'x' than capabilities. You can now ask the rather more useful question am I allowed to do 'X' and the answer may well depend upon selinux, trust models and what have you as well as securelevels and other concepts anyone wishes to play with (things like remote attestation for example) A simple minded adjustment to cap_capable would then be to make cap_is_permitted what cap_capable is now but with cap = security_required_capability[x]; if (cap == -1) return 0; Prior to adding anything or considered measured kernels that would be a 1:1 mapping. Nothing breaks, nothing exciting happens. But you can now add new permissions and map them about. So you can mark some of the RAW_IO ones with new names and in non trusted kernels they get given a map value of CAP_SYS_RAWIO, or in trusted cases -1. At that point we've got - an automated conversion for the non-measured case, so we don't screw up a long change set. - no breakages of userspace in the non measured case (and we can test at this point quite happily) - a single interface, because driver authors can't be expected to understand two differently broken interacting sets of checks (plus since we just got rid of capable they can't forget to update their code or copy old now broken but happily compiling code). - a way to fix the existing capable() mess - a way to support measured kernels by adding new permissions without them breaking non measured userspace cases, without breaking the capability model seen from userspace. So for example we can add RIGHT_LOAD_SIGNED_FIRMWARE RIGHT_LOAD_UNSIGNED_FIRMWARE etc and we can tie them to things other than CAP_SYS_RAWIO in untrusted mode. Indeed it wouldn't be hard to make the table two dimensional cap = security_required_capability[measured_kernel()][x]; and just mark the 'generic' RIGHT_RAW_IO_ACCESS as -1 in trusted mode but CAP_SYS_RAWIO if not, while RIGHT_LOAD_SIGNED_FIRMWARE is CAP_SYS_RAWIO in both cases. - a whitelist type behaviour. If the default for RIGHT_RAW_IO_ACCESS is -1 in trusted mode then only the cases someone goes back and explicitly refines will get enabled. Anyone adding a driver or blindly copying the old behaviours either breaks or if they blindly convert gets the safe behaviour. - a way to allow security modules to make smarter decisions because they all have the ability
Re: Trusted kernel patchset for Secure Boot lockdown
> The command line problem here is a total red herring. If you've got a > measured kernel, you have a measured command line. (If not, you don't That would be the sensible approach, but it has some quite drastic ramifications. > have a measured kernel.) Dealing with the command line has nothing to > do with enforcing the ring0/uid0 boundary which is what this patch > series does. It has a huge relevance. You are signing blocks of code and loading them into your kernel. In case it's escaped your notice those blocks of code have behaviour which is considerably customisable by passing module arguments to them. In many cases they don't actually check those arguments. If I can set module paramters I already 0wn your box so many different ways its not even funny. > Right. As mentioned, we've been over all of this before. We cannot > change the meaning of capabilities (nor expand their coverage to > existing interfaces) without breaking userspace. Since we cannot break > userspace, we must create a different policy system that covers this > new thing we want to do and keeps the new policy distinctly separate. So you have everything checked twice all over the kernel and you guarantee that people will get it wrong. I don't see the point of putting a broken implementation in the kernel. If you want to do security do it *right* and do it once. You think every single person who adds a driver is going to muddle through two interfaces (and in future no doubt more if we don't fix it properly) and get it right each time ? The 'breaking userspace' argument is bullshit already. The whole *point* of the measured kernel is to break userspace. You are deliberately breaking a pile of functionality, much of it undersirable in order to achieve your measured system. The only "don't break" case that matters is if the measured stuff isn't in use. In those cases we don't need to break anything. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 08:54 -0700, Kees Cook wrote: > All the more reason to ignore command line at this point. For Chrome > OS, it's part of our boot state, so we don't care about it. For > generic Secure Boot, we can add checks for dangerous stuff as we go > forward. That's why I like this interface -- we can add to it as we > identify bad stuff, and it stay separate from other semantics. Sure, it's just another reason not to want to use a capability-based interface - not all the policy we want to impose is related to processes, so capabilities really don't make sense. The current patchset adds a restriction to the acpi_rsdp argument, and I've no objection to adding one to limit the use of mem=. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 8:46 AM, Matthew Garrett wrote: > On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote: > >> The command line problem here is a total red herring. If you've got a >> measured kernel, you have a measured command line. (If not, you don't >> have a measured kernel.) Dealing with the command line has nothing to >> do with enforcing the ring0/uid0 boundary which is what this patch >> series does. > > That's why I used trusted rather than measured. The Secure Boot trust > model assumes that the user is able to modify the command line (it's > basically impossible to deploy generically otherwise), so we need to > filter out command line options that allow a user to elevate themselves > into the kernel at boot time. All the more reason to ignore command line at this point. For Chrome OS, it's part of our boot state, so we don't care about it. For generic Secure Boot, we can add checks for dangerous stuff as we go forward. That's why I like this interface -- we can add to it as we identify bad stuff, and it stay separate from other semantics. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote: > The command line problem here is a total red herring. If you've got a > measured kernel, you have a measured command line. (If not, you don't > have a measured kernel.) Dealing with the command line has nothing to > do with enforcing the ring0/uid0 boundary which is what this patch > series does. That's why I used trusted rather than measured. The Secure Boot trust model assumes that the user is able to modify the command line (it's basically impossible to deploy generically otherwise), so we need to filter out command line options that allow a user to elevate themselves into the kernel at boot time. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 5:51 AM, Matthew Garrett wrote: > On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote: >> > Have you actually looked at these patches? I've looked at every case of >> > RAWIO in the kernel. For cases that are hardware specific and tied to >> > fairly old hardware, I've ignored them. For cases which provide an >> >> Yes I have - and it's not exactly localised: it modifies stuff all over >> the tree when it shouldn't need to. It's a security policy. If it leaks >> policy all over the kernel then the implementation model is *wrong*. > > But you keep talking about MSRs despite there being a patch that limits > access to MSRs. If you have specific examples of privilege escalations > that are possible even with these patches then please, mention them. > >> > >default behaviour for capable(x) in fact be >> > > >> > >capable(x & ~secure_forbidden) >> > > >> > >for a measured kernel and add a >> > > >> > >capable_always() >> > > >> > >for the cases you want to not break. >> > >> > We could do that, but now the behaviour of the patchset is far less >> > obvious. capable(CAP_SYS_RAWIO) now means something different to every >> > other use of capable(), and we still need get_trusted_kernel() calls for >> > cases where the checks have nothing to do with processes and so >> > capabilities can't be used. And this ignores the fact that being able to query the measured state is potentially valuable to additional security policies (e.g. module loading, firmware loading). Hiding the measured logic in capabilities makes no sense -- they're orthogonal restrictions. >> >> You don't need get_measured_kernel() calls because thats hidden within >> capable/capable_always. And if the interaction is a complicated as you >> imply that again says to me the model is wrong. Complicated multi-way >> security interactions lead to complicated exploits leveraging the >> disconnects. > > How is capable() going to be any use when deciding whether or not to > interpret some kernel command line options? The command line problem here is a total red herring. If you've got a measured kernel, you have a measured command line. (If not, you don't have a measured kernel.) Dealing with the command line has nothing to do with enforcing the ring0/uid0 boundary which is what this patch series does. >> > We can do this without unnecessarily breaking any userspace. We just >> > can't do it by fiddling with capabilities. >> >> It should still be a security model nto spreading measured_kernel() >> checks about. Now if that means >> >> capable(CAP_SYS_RAWIO) >> >> should become security-> interface hooks that pass something meaningful >> to the security layer then I'd rather we did the job properly in the first >> place and put the policy in one spot not all over the kernel. > > We still need a mechanism to differentiate between cases where > CAP_SYS_RAWIO should be forbidden and cases where it should be > permitted, which means that we need to add additional policy. We can > modify capable(), but that means that capable() no longer does what you > expect it to - it's not a transparent interface, and that's likely to > result in people accidentally misusing it. > >> The question then becomes what do we need to pass beyond "CAP_SYS_RAWIO" >> so the policy can be in the right place - even for example imposed by >> SELinux rules. > > It needs to be possible for this policy to be imposed without userspace > being involved, so using selinux would mean baking it into the kernel > (along with an additional implementation for apparmor, and presumably > one for tomoyo as well). > >> >> > > I don't think we need to break any userspace for "normal" mode to do >> > > this. Userspace in measured mode is going to change anyway. It already >> > > has just for things like module signing. >> > >> > This has been discussed at length. Nobody who's actually spent time >> > working on the problem wants to use capabilities. CAP_SYS_RAWIO is not >> > semantically identical to the trusted kernel bit. Trying to make them >> > semantically identical will break existing userspace. >> >> I never said it was. I said that getting rid of CAP_SYS_RAWIO and then >> dealing with *just* the exceptions to this is a lot cleaner, and likely >> to be more secure. > > And will give us the choice between complicating a simple interface or > breaking userspace. If the maintainer believes that's a better approach > then I can rewrite all of this again, but so far you seem to be in a > minority on this front. > >> In addition several of the cases that you point out could be fixed by >> replacing the CAP_SYS_RAWIO using stuff with a proper interface should >> probably just be *fixed* to provide that. > > ...thus breaking userspace outside this use case. I mean, sure, I'm > absolutely fine with deleting /dev/mem entirely. I don't see Linus > agreeing. Right. As mentioned, we've been over all of this before. We cannot change the meaning of
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote: > > Have you actually looked at these patches? I've looked at every case of > > RAWIO in the kernel. For cases that are hardware specific and tied to > > fairly old hardware, I've ignored them. For cases which provide an > > Yes I have - and it's not exactly localised: it modifies stuff all over > the tree when it shouldn't need to. It's a security policy. If it leaks > policy all over the kernel then the implementation model is *wrong*. But you keep talking about MSRs despite there being a patch that limits access to MSRs. If you have specific examples of privilege escalations that are possible even with these patches then please, mention them. > > >default behaviour for capable(x) in fact be > > > > > >capable(x & ~secure_forbidden) > > > > > >for a measured kernel and add a > > > > > >capable_always() > > > > > >for the cases you want to not break. > > > > We could do that, but now the behaviour of the patchset is far less > > obvious. capable(CAP_SYS_RAWIO) now means something different to every > > other use of capable(), and we still need get_trusted_kernel() calls for > > cases where the checks have nothing to do with processes and so > > capabilities can't be used. > > You don't need get_measured_kernel() calls because thats hidden within > capable/capable_always. And if the interaction is a complicated as you > imply that again says to me the model is wrong. Complicated multi-way > security interactions lead to complicated exploits leveraging the > disconnects. How is capable() going to be any use when deciding whether or not to interpret some kernel command line options? > > We can do this without unnecessarily breaking any userspace. We just > > can't do it by fiddling with capabilities. > > It should still be a security model nto spreading measured_kernel() > checks about. Now if that means > > capable(CAP_SYS_RAWIO) > > should become security-> interface hooks that pass something meaningful > to the security layer then I'd rather we did the job properly in the first > place and put the policy in one spot not all over the kernel. We still need a mechanism to differentiate between cases where CAP_SYS_RAWIO should be forbidden and cases where it should be permitted, which means that we need to add additional policy. We can modify capable(), but that means that capable() no longer does what you expect it to - it's not a transparent interface, and that's likely to result in people accidentally misusing it. > The question then becomes what do we need to pass beyond "CAP_SYS_RAWIO" > so the policy can be in the right place - even for example imposed by > SELinux rules. It needs to be possible for this policy to be imposed without userspace being involved, so using selinux would mean baking it into the kernel (along with an additional implementation for apparmor, and presumably one for tomoyo as well). > > > > I don't think we need to break any userspace for "normal" mode to do > > > this. Userspace in measured mode is going to change anyway. It already > > > has just for things like module signing. > > > > This has been discussed at length. Nobody who's actually spent time > > working on the problem wants to use capabilities. CAP_SYS_RAWIO is not > > semantically identical to the trusted kernel bit. Trying to make them > > semantically identical will break existing userspace. > > I never said it was. I said that getting rid of CAP_SYS_RAWIO and then > dealing with *just* the exceptions to this is a lot cleaner, and likely > to be more secure. And will give us the choice between complicating a simple interface or breaking userspace. If the maintainer believes that's a better approach then I can rewrite all of this again, but so far you seem to be in a minority on this front. > In addition several of the cases that you point out could be fixed by > replacing the CAP_SYS_RAWIO using stuff with a proper interface should > probably just be *fixed* to provide that. ...thus breaking userspace outside this use case. I mean, sure, I'm absolutely fine with deleting /dev/mem entirely. I don't see Linus agreeing. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
> Have you actually looked at these patches? I've looked at every case of > RAWIO in the kernel. For cases that are hardware specific and tied to > fairly old hardware, I've ignored them. For cases which provide an Yes I have - and it's not exactly localised: it modifies stuff all over the tree when it shouldn't need to. It's a security policy. If it leaks policy all over the kernel then the implementation model is *wrong*. > >default behaviour for capable(x) in fact be > > > >capable(x & ~secure_forbidden) > > > >for a measured kernel and add a > > > >capable_always() > > > >for the cases you want to not break. > > We could do that, but now the behaviour of the patchset is far less > obvious. capable(CAP_SYS_RAWIO) now means something different to every > other use of capable(), and we still need get_trusted_kernel() calls for > cases where the checks have nothing to do with processes and so > capabilities can't be used. You don't need get_measured_kernel() calls because thats hidden within capable/capable_always. And if the interaction is a complicated as you imply that again says to me the model is wrong. Complicated multi-way security interactions lead to complicated exploits leveraging the disconnects. But see further down... > > As for mem= and exactmap, it has nothing to do with /dev/mem and > > everything to do with giving the kernel a memory map where some of the > > space it thinks is RAM is in fact devices, rom, space etc. If the kernel > > is given a false memory map it will misbehave. Exploitably - well given > > the kind of things people have achieved in the past - quite possibly. > > Sure. That's a worthwhile thing to fix, and it's something that dropping > CAP_SYS_RAWIO would do nothing to help you with. I didn't mention it with regards to CAP_SYS_RAWIO, just as a general example of stuff not dealt with. Again that one really suggests that the right approach is to whitelist allowed boot options not blacklist bad ones. It's the usual story with security, people fight bitterly not to do whitelisting, then spend two years and more effort fixing holes than doing whitelisting then eventually have to whitelist anyway. (or maybe I'm just bitter and cynical) > We can do this without unnecessarily breaking any userspace. We just > can't do it by fiddling with capabilities. It should still be a security model nto spreading measured_kernel() checks about. Now if that means capable(CAP_SYS_RAWIO) should become security-> interface hooks that pass something meaningful to the security layer then I'd rather we did the job properly in the first place and put the policy in one spot not all over the kernel. The question then becomes what do we need to pass beyond "CAP_SYS_RAWIO" so the policy can be in the right place - even for example imposed by SELinux rules. > > I don't think we need to break any userspace for "normal" mode to do > > this. Userspace in measured mode is going to change anyway. It already > > has just for things like module signing. > > This has been discussed at length. Nobody who's actually spent time > working on the problem wants to use capabilities. CAP_SYS_RAWIO is not > semantically identical to the trusted kernel bit. Trying to make them > semantically identical will break existing userspace. I never said it was. I said that getting rid of CAP_SYS_RAWIO and then dealing with *just* the exceptions to this is a lot cleaner, and likely to be more secure. Right now the 'measured' patches spew all over the place. That shouldn't be needed. In addition several of the cases that you point out could be fixed by replacing the CAP_SYS_RAWIO using stuff with a proper interface should probably just be *fixed* to provide that. > > (As an aside you may also then want to think about whether you allow > > measured userspace elements that secure_forbidden is considered to be 0 > > for so you can sign userspace apps that are allowed to do RAWIO) > > I'd be amazed if any of the applications that need RAWIO have had any > kind of meaningful security audit How re-assuring ;) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
Have you actually looked at these patches? I've looked at every case of RAWIO in the kernel. For cases that are hardware specific and tied to fairly old hardware, I've ignored them. For cases which provide an Yes I have - and it's not exactly localised: it modifies stuff all over the tree when it shouldn't need to. It's a security policy. If it leaks policy all over the kernel then the implementation model is *wrong*. default behaviour for capable(x) in fact be capable(x ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. We could do that, but now the behaviour of the patchset is far less obvious. capable(CAP_SYS_RAWIO) now means something different to every other use of capable(), and we still need get_trusted_kernel() calls for cases where the checks have nothing to do with processes and so capabilities can't be used. You don't need get_measured_kernel() calls because thats hidden within capable/capable_always. And if the interaction is a complicated as you imply that again says to me the model is wrong. Complicated multi-way security interactions lead to complicated exploits leveraging the disconnects. But see further down... As for mem= and exactmap, it has nothing to do with /dev/mem and everything to do with giving the kernel a memory map where some of the space it thinks is RAM is in fact devices, rom, space etc. If the kernel is given a false memory map it will misbehave. Exploitably - well given the kind of things people have achieved in the past - quite possibly. Sure. That's a worthwhile thing to fix, and it's something that dropping CAP_SYS_RAWIO would do nothing to help you with. I didn't mention it with regards to CAP_SYS_RAWIO, just as a general example of stuff not dealt with. Again that one really suggests that the right approach is to whitelist allowed boot options not blacklist bad ones. It's the usual story with security, people fight bitterly not to do whitelisting, then spend two years and more effort fixing holes than doing whitelisting then eventually have to whitelist anyway. (or maybe I'm just bitter and cynical) We can do this without unnecessarily breaking any userspace. We just can't do it by fiddling with capabilities. It should still be a security model nto spreading measured_kernel() checks about. Now if that means capable(CAP_SYS_RAWIO) should become security- interface hooks that pass something meaningful to the security layer then I'd rather we did the job properly in the first place and put the policy in one spot not all over the kernel. The question then becomes what do we need to pass beyond CAP_SYS_RAWIO so the policy can be in the right place - even for example imposed by SELinux rules. I don't think we need to break any userspace for normal mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. This has been discussed at length. Nobody who's actually spent time working on the problem wants to use capabilities. CAP_SYS_RAWIO is not semantically identical to the trusted kernel bit. Trying to make them semantically identical will break existing userspace. I never said it was. I said that getting rid of CAP_SYS_RAWIO and then dealing with *just* the exceptions to this is a lot cleaner, and likely to be more secure. Right now the 'measured' patches spew all over the place. That shouldn't be needed. In addition several of the cases that you point out could be fixed by replacing the CAP_SYS_RAWIO using stuff with a proper interface should probably just be *fixed* to provide that. (As an aside you may also then want to think about whether you allow measured userspace elements that secure_forbidden is considered to be 0 for so you can sign userspace apps that are allowed to do RAWIO) I'd be amazed if any of the applications that need RAWIO have had any kind of meaningful security audit How re-assuring ;) Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote: Have you actually looked at these patches? I've looked at every case of RAWIO in the kernel. For cases that are hardware specific and tied to fairly old hardware, I've ignored them. For cases which provide an Yes I have - and it's not exactly localised: it modifies stuff all over the tree when it shouldn't need to. It's a security policy. If it leaks policy all over the kernel then the implementation model is *wrong*. But you keep talking about MSRs despite there being a patch that limits access to MSRs. If you have specific examples of privilege escalations that are possible even with these patches then please, mention them. default behaviour for capable(x) in fact be capable(x ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. We could do that, but now the behaviour of the patchset is far less obvious. capable(CAP_SYS_RAWIO) now means something different to every other use of capable(), and we still need get_trusted_kernel() calls for cases where the checks have nothing to do with processes and so capabilities can't be used. You don't need get_measured_kernel() calls because thats hidden within capable/capable_always. And if the interaction is a complicated as you imply that again says to me the model is wrong. Complicated multi-way security interactions lead to complicated exploits leveraging the disconnects. How is capable() going to be any use when deciding whether or not to interpret some kernel command line options? We can do this without unnecessarily breaking any userspace. We just can't do it by fiddling with capabilities. It should still be a security model nto spreading measured_kernel() checks about. Now if that means capable(CAP_SYS_RAWIO) should become security- interface hooks that pass something meaningful to the security layer then I'd rather we did the job properly in the first place and put the policy in one spot not all over the kernel. We still need a mechanism to differentiate between cases where CAP_SYS_RAWIO should be forbidden and cases where it should be permitted, which means that we need to add additional policy. We can modify capable(), but that means that capable() no longer does what you expect it to - it's not a transparent interface, and that's likely to result in people accidentally misusing it. The question then becomes what do we need to pass beyond CAP_SYS_RAWIO so the policy can be in the right place - even for example imposed by SELinux rules. It needs to be possible for this policy to be imposed without userspace being involved, so using selinux would mean baking it into the kernel (along with an additional implementation for apparmor, and presumably one for tomoyo as well). I don't think we need to break any userspace for normal mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. This has been discussed at length. Nobody who's actually spent time working on the problem wants to use capabilities. CAP_SYS_RAWIO is not semantically identical to the trusted kernel bit. Trying to make them semantically identical will break existing userspace. I never said it was. I said that getting rid of CAP_SYS_RAWIO and then dealing with *just* the exceptions to this is a lot cleaner, and likely to be more secure. And will give us the choice between complicating a simple interface or breaking userspace. If the maintainer believes that's a better approach then I can rewrite all of this again, but so far you seem to be in a minority on this front. In addition several of the cases that you point out could be fixed by replacing the CAP_SYS_RAWIO using stuff with a proper interface should probably just be *fixed* to provide that. ...thus breaking userspace outside this use case. I mean, sure, I'm absolutely fine with deleting /dev/mem entirely. I don't see Linus agreeing. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 5:51 AM, Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote: Have you actually looked at these patches? I've looked at every case of RAWIO in the kernel. For cases that are hardware specific and tied to fairly old hardware, I've ignored them. For cases which provide an Yes I have - and it's not exactly localised: it modifies stuff all over the tree when it shouldn't need to. It's a security policy. If it leaks policy all over the kernel then the implementation model is *wrong*. But you keep talking about MSRs despite there being a patch that limits access to MSRs. If you have specific examples of privilege escalations that are possible even with these patches then please, mention them. default behaviour for capable(x) in fact be capable(x ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. We could do that, but now the behaviour of the patchset is far less obvious. capable(CAP_SYS_RAWIO) now means something different to every other use of capable(), and we still need get_trusted_kernel() calls for cases where the checks have nothing to do with processes and so capabilities can't be used. And this ignores the fact that being able to query the measured state is potentially valuable to additional security policies (e.g. module loading, firmware loading). Hiding the measured logic in capabilities makes no sense -- they're orthogonal restrictions. You don't need get_measured_kernel() calls because thats hidden within capable/capable_always. And if the interaction is a complicated as you imply that again says to me the model is wrong. Complicated multi-way security interactions lead to complicated exploits leveraging the disconnects. How is capable() going to be any use when deciding whether or not to interpret some kernel command line options? The command line problem here is a total red herring. If you've got a measured kernel, you have a measured command line. (If not, you don't have a measured kernel.) Dealing with the command line has nothing to do with enforcing the ring0/uid0 boundary which is what this patch series does. We can do this without unnecessarily breaking any userspace. We just can't do it by fiddling with capabilities. It should still be a security model nto spreading measured_kernel() checks about. Now if that means capable(CAP_SYS_RAWIO) should become security- interface hooks that pass something meaningful to the security layer then I'd rather we did the job properly in the first place and put the policy in one spot not all over the kernel. We still need a mechanism to differentiate between cases where CAP_SYS_RAWIO should be forbidden and cases where it should be permitted, which means that we need to add additional policy. We can modify capable(), but that means that capable() no longer does what you expect it to - it's not a transparent interface, and that's likely to result in people accidentally misusing it. The question then becomes what do we need to pass beyond CAP_SYS_RAWIO so the policy can be in the right place - even for example imposed by SELinux rules. It needs to be possible for this policy to be imposed without userspace being involved, so using selinux would mean baking it into the kernel (along with an additional implementation for apparmor, and presumably one for tomoyo as well). I don't think we need to break any userspace for normal mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. This has been discussed at length. Nobody who's actually spent time working on the problem wants to use capabilities. CAP_SYS_RAWIO is not semantically identical to the trusted kernel bit. Trying to make them semantically identical will break existing userspace. I never said it was. I said that getting rid of CAP_SYS_RAWIO and then dealing with *just* the exceptions to this is a lot cleaner, and likely to be more secure. And will give us the choice between complicating a simple interface or breaking userspace. If the maintainer believes that's a better approach then I can rewrite all of this again, but so far you seem to be in a minority on this front. In addition several of the cases that you point out could be fixed by replacing the CAP_SYS_RAWIO using stuff with a proper interface should probably just be *fixed* to provide that. ...thus breaking userspace outside this use case. I mean, sure, I'm absolutely fine with deleting /dev/mem entirely. I don't see Linus agreeing. Right. As mentioned, we've been over all of this before. We cannot change the meaning of capabilities (nor expand their coverage to existing interfaces) without breaking userspace. Since we cannot break userspace, we must create a different policy system that
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote: The command line problem here is a total red herring. If you've got a measured kernel, you have a measured command line. (If not, you don't have a measured kernel.) Dealing with the command line has nothing to do with enforcing the ring0/uid0 boundary which is what this patch series does. That's why I used trusted rather than measured. The Secure Boot trust model assumes that the user is able to modify the command line (it's basically impossible to deploy generically otherwise), so we need to filter out command line options that allow a user to elevate themselves into the kernel at boot time. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 8:46 AM, Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote: The command line problem here is a total red herring. If you've got a measured kernel, you have a measured command line. (If not, you don't have a measured kernel.) Dealing with the command line has nothing to do with enforcing the ring0/uid0 boundary which is what this patch series does. That's why I used trusted rather than measured. The Secure Boot trust model assumes that the user is able to modify the command line (it's basically impossible to deploy generically otherwise), so we need to filter out command line options that allow a user to elevate themselves into the kernel at boot time. All the more reason to ignore command line at this point. For Chrome OS, it's part of our boot state, so we don't care about it. For generic Secure Boot, we can add checks for dangerous stuff as we go forward. That's why I like this interface -- we can add to it as we identify bad stuff, and it stay separate from other semantics. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 08:54 -0700, Kees Cook wrote: All the more reason to ignore command line at this point. For Chrome OS, it's part of our boot state, so we don't care about it. For generic Secure Boot, we can add checks for dangerous stuff as we go forward. That's why I like this interface -- we can add to it as we identify bad stuff, and it stay separate from other semantics. Sure, it's just another reason not to want to use a capability-based interface - not all the policy we want to impose is related to processes, so capabilities really don't make sense. The current patchset adds a restriction to the acpi_rsdp argument, and I've no objection to adding one to limit the use of mem=. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
The command line problem here is a total red herring. If you've got a measured kernel, you have a measured command line. (If not, you don't That would be the sensible approach, but it has some quite drastic ramifications. have a measured kernel.) Dealing with the command line has nothing to do with enforcing the ring0/uid0 boundary which is what this patch series does. It has a huge relevance. You are signing blocks of code and loading them into your kernel. In case it's escaped your notice those blocks of code have behaviour which is considerably customisable by passing module arguments to them. In many cases they don't actually check those arguments. If I can set module paramters I already 0wn your box so many different ways its not even funny. Right. As mentioned, we've been over all of this before. We cannot change the meaning of capabilities (nor expand their coverage to existing interfaces) without breaking userspace. Since we cannot break userspace, we must create a different policy system that covers this new thing we want to do and keeps the new policy distinctly separate. So you have everything checked twice all over the kernel and you guarantee that people will get it wrong. I don't see the point of putting a broken implementation in the kernel. If you want to do security do it *right* and do it once. You think every single person who adds a driver is going to muddle through two interfaces (and in future no doubt more if we don't fix it properly) and get it right each time ? The 'breaking userspace' argument is bullshit already. The whole *point* of the measured kernel is to break userspace. You are deliberately breaking a pile of functionality, much of it undersirable in order to achieve your measured system. The only don't break case that matters is if the measured stuff isn't in use. In those cases we don't need to break anything. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
But you keep talking about MSRs despite there being a patch that limits access to MSRs. If you have specific examples of privilege escalations that are possible even with these patches then please, mention them. I mentioned MSRs once, and then you kept going on about it. Your patches are all over the tree, for what should be one piece of policy. They rely on not missing a single case, which is also bad security engineering. We know that, as an industry we've spent fifty years repeatedly sticking our fingers in our ears, refusing to listen and then learning it again and again the hard way. How is capable() going to be any use when deciding whether or not to interpret some kernel command line options? I have no idea, why are you asking such an odd question ? You need to whitelist module parameters and boot options that are safe in your measured kernel environment. Nothing to do with RAWIO or capable(), just that we have thousands of such options many of which are quite exploitable because they assume the loader is trustable (which btw is already *broken* and on many systems - eg Fedora - allows you to break from DAC override into RAWIO). That one actually wants cleaning up anyway but its hard to see the right way to do it. We still need a mechanism to differentiate between cases where CAP_SYS_RAWIO should be forbidden and cases where it should be permitted, which means that we need to add additional policy. We can modify capable(), but that means that capable() no longer does what you expect it to - it's not a transparent interface, and that's likely to result in people accidentally misusing it. capable() is not a good interface. If we are going to patch half the capable() calls in the kernel wouldn't it be a good time to actually do something about it properly ? At the very least we should turn capabilities/needs into two lists and make them a 2D grid so we break the tie between the userspace 'capability' and 'what this allows you to do in this specific instance'. For example instead of spewing magic trusted kernel checks all over the place we could do a global seach/replace of most of the capable calls with is_permitted(x) where x is a value indicating what we wish to do (action) not what right we need (policy). All the real mess comes from the fact that capable() is implementing security *policy* in drivers all over the kernel. You can then set up a map of capability to X values, and more importantly you can use that map to have more complete, and descriptive versions of 'x' than capabilities. You can now ask the rather more useful question am I allowed to do 'X' and the answer may well depend upon selinux, trust models and what have you as well as securelevels and other concepts anyone wishes to play with (things like remote attestation for example) A simple minded adjustment to cap_capable would then be to make cap_is_permitted what cap_capable is now but with cap = security_required_capability[x]; if (cap == -1) return 0; Prior to adding anything or considered measured kernels that would be a 1:1 mapping. Nothing breaks, nothing exciting happens. But you can now add new permissions and map them about. So you can mark some of the RAW_IO ones with new names and in non trusted kernels they get given a map value of CAP_SYS_RAWIO, or in trusted cases -1. At that point we've got - an automated conversion for the non-measured case, so we don't screw up a long change set. - no breakages of userspace in the non measured case (and we can test at this point quite happily) - a single interface, because driver authors can't be expected to understand two differently broken interacting sets of checks (plus since we just got rid of capable they can't forget to update their code or copy old now broken but happily compiling code). - a way to fix the existing capable() mess - a way to support measured kernels by adding new permissions without them breaking non measured userspace cases, without breaking the capability model seen from userspace. So for example we can add RIGHT_LOAD_SIGNED_FIRMWARE RIGHT_LOAD_UNSIGNED_FIRMWARE etc and we can tie them to things other than CAP_SYS_RAWIO in untrusted mode. Indeed it wouldn't be hard to make the table two dimensional cap = security_required_capability[measured_kernel()][x]; and just mark the 'generic' RIGHT_RAW_IO_ACCESS as -1 in trusted mode but CAP_SYS_RAWIO if not, while RIGHT_LOAD_SIGNED_FIRMWARE is CAP_SYS_RAWIO in both cases. - a whitelist type behaviour. If the default for RIGHT_RAW_IO_ACCESS is -1 in trusted mode then only the cases someone goes back and explicitly refines will get enabled. Anyone adding a driver or blindly copying the old behaviours either breaks or if they blindly convert gets the safe behaviour. - a way to allow security modules to make smarter decisions because they all have the ability to
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 17:06 +, One Thousand Gnomes wrote: But you keep talking about MSRs despite there being a patch that limits access to MSRs. If you have specific examples of privilege escalations that are possible even with these patches then please, mention them. I mentioned MSRs once, and then you kept going on about it. You've twice mentioned MSRs as a case where CAP_SYS_RAWIO allows you to elevate privileges, despite that being a case that's explicitly covered by this patchset. Now, do you have an actual example of CAP_SYS_RAWIO allowing you to elevate privileges even with this patchset applied (and without requiring the presence of obsolete hardware, which is a separate conversation)? Your patches are all over the tree, for what should be one piece of policy. They rely on not missing a single case, which is also bad security engineering. We know that, as an industry we've spent fifty years repeatedly sticking our fingers in our ears, refusing to listen and then learning it again and again the hard way. I have a set of patches that appear acceptable to the security maintainer. I've rewritten them multiple times in response to various levels of bikeshedding. They solve a real problem and are being shipped by multiple distributions. What the rest of your mail is asking me to do is to rewrite capabilities support entirely. Now, yes, I agree that capabilities are an awful interface that's approximately impossible to use correctly and which adds little security even if you do. But I reject the idea that rewriting fundamental security infrastructure should be a prerequisite for adding this functionality. It needs to be possible for this policy to be imposed without userspace being involved, so using selinux would mean baking it into the kernel (along with an additional implementation for apparmor, and presumably one for tomoyo as well). That's clearly false. You can load signed modules so you can load signed policies. Assuming you don't have an initial measured file system you need a kernel policy initially that protects you. If you have a measured file system you don't even need that, nor do you need to revoke RAWIO in kernel, you can do it before you switch into measured and running un-measured code mode - ie about the point you pivot root out of the initrd that loaded the measured policy. We can't rely on userspace choosing to load that policy. We don't have a measured filesystem. The initrd is not signed (and nor can it be). The kernel itself *must* impose policy. ...thus breaking userspace outside this use case. I mean, sure, I'm absolutely fine with deleting /dev/mem entirely. I don't see Linus agreeing. That's not what I meant. We have a lot of interfaces where we use CAP_SYS_RAWIO rather than having a structured interface as opposed to a 'yeah whatever, poke the registers' interface. For a lot of environments btw you don't actually need /dev/mem. It's not really got a lot of uses any more and plenty of people really restrict or remove it from systems. I don't think very many people would be sad if /dev/mem became a legacy interface most people left turned off. Sure! Except then A Large Vendor's custom IPMI userspace stops working, even on systems without Secure Boot, and then said Large Vendor wants to have conference calls at times that are convenient for Japan and then this is an issue that's going to cause $1 billion in lost sales and come on, you've been there. You know that this isn't going to work. If we are going to do a measured kernel then it needs to be done right, it needs to be properly abstracted so we don't add another one for Android, another one for Chrome, another one for ARM trustzone, another one for Intel SGX, and so on. The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
simply an assertion that the firmware (which you're forced to trust)
chose, via some policy you may be unaware of, to trust the booted
kernel.
As an example, imagine a platform with the bootloader and kernel on
read-only media. The platform can assert that the kernel is trusted even
if there's no measurement of the kernel.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014, Matthew Garrett wrote: On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote: The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. As an example, imagine a platform with the bootloader and kernel on read-only media. The platform can assert that the kernel is trusted even if there's no measurement of the kernel. Trusted by who? Alan is saying measured because then if it matches what the owner of that device intends it's trusted, but just because you trust it doesn't mean that I trust it, and it doesn't mean that the russian government should trust it, etc. There just isn't one value of trust. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 13:37 -0700, David Lang wrote: On Fri, 14 Mar 2014, Matthew Garrett wrote: As an example, imagine a platform with the bootloader and kernel on read-only media. The platform can assert that the kernel is trusted even if there's no measurement of the kernel. Trusted by who? The platform. If you don't trust the platform's ability to make that decision then that's something that informs your own behaviour, not the platform's. Alan is saying measured because then if it matches what the owner of that device intends it's trusted, but just because you trust it doesn't mean that I trust it, and it doesn't mean that the russian government should trust it, etc. Measured has a specific meaning. If you trust a file based on its source rather than some property of the file itself, you're not measuring it. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
I have a set of patches that appear acceptable to the security maintainer. I've rewritten them multiple times in response to various levels of bikeshedding. They solve a real problem and are being shipped by multiple distributions. And ? I've seen some of the other extra stuff distributions ship. Lots of it is hilariously bad. That really isn't a good argument for the code - for the feature yes. What the rest of your mail is asking me to do is to rewrite capabilities support entirely. Now, yes, I agree that capabilities are an awful interface that's approximately impossible to use correctly and which adds little security even if you do. But I reject the idea that rewriting fundamental security infrastructure should be a prerequisite for adding this functionality. Actually it's nothing of the sort. It's a proposal to do it. It's 90% a regexp task. I'm offering to go and do that bit. I am quite happy to do the capability crapfest fixing. It wants doing *anyway*. But if I got do that work, does it solve your problem ? I think it does but I'd like to be sure. It needs to be possible for this policy to be imposed without userspace being involved, so using selinux would mean baking it into the kernel (along with an additional implementation for apparmor, and presumably one for tomoyo as well). That's clearly false. You can load signed modules so you can load signed policies. Assuming you don't have an initial measured file system you need a kernel policy initially that protects you. If you have a measured file system you don't even need that, nor do you need to revoke RAWIO in kernel, you can do it before you switch into measured and running un-measured code mode - ie about the point you pivot root out of the initrd that loaded the measured policy. We can't rely on userspace choosing to load that policy. We don't have a measured filesystem. The initrd is not signed (and nor can it be). The kernel itself *must* impose policy. In your particularly implementation maybe you've got a weak setup where you don't measure down to your initrd. That's a *flaw* in your implementation. Don't inflict your limitations on others or on the future. EFI is only one (and not a very strong one at that) implementation of a 'secure' boot chain. A lot of other systems can not only propogate measurement and security assertions into their initrd they can propogate them into their rootfs (yes upgrades are .. exciting, but these kinds of users will live with that pain). Even in EFI you can make your kernel or loader check the initrd signature and the rootfs signature if you want. Sure! Except then A Large Vendor's custom IPMI userspace stops working, even on systems without Secure Boot, and then said Large Vendor wants to have conference calls at times that are convenient for Japan and then this is an issue that's going to cause $1 billion in lost sales and come on, you've been there. You know that this isn't going to work. That's not an upstream problem (but with my work hat on I understand your position). Anyway they'll be running someones enterprise product which will have legacy enabled out of the wazoo so their customers 15 year old we lost the code blob that nobody can even remember what it does still works 8) If we are going to do a measured kernel then it needs to be done right, it needs to be properly abstracted so we don't add another one for Android, another one for Chrome, another one for ARM trustzone, another one for Intel SGX, and so on. The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. You are currently using some of those interfaces for measuring to produce a notionally 'trusted' initial loaded environment. Correct me if I am wrong but your starting point is I have a chain of measurement as far as the kernel I load. Without that I can just go into grub and 0wn you. There are multiple things you want to do in measured environments, stopping people sneakily loading new kernels is one of them. If you want to talk about secure that implies a whole load more than ring 0 hacks. It implies having a model where not only has J Random smart hacker gone over the code and hacked all the call points, but that someone has done some kind of formal review of it, used good security practices like whitelisting and thought very hard about the rest of the exposed surfaces. Otherwise its security theatre, it's marketing fluff. We've got lots of marketing security fluff in the kernel, we don't need more of it. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote:
In your particularly implementation maybe you've got a weak setup where
you don't measure down to your initrd. That's a *flaw* in your
implementation. Don't inflict your limitations on others or on the
future. EFI is only one (and not a very strong one at that) implementation
of a 'secure' boot chain. A lot of other systems can not only propogate
measurement and security assertions into their initrd they can propogate
them into their rootfs (yes upgrades are .. exciting, but these kinds of
users will live with that pain).
Signed userspace is not a requirement, and therefore any solution that
relies on a signed initrd is inadequate. There are use cases that
require verification of the initrd and other levels. This isn't one of
them.
Even in EFI you can make your kernel or loader check the initrd signature
and the rootfs signature if you want.
Except the initramfs gets built at kernel install time.
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
simply an assertion that the firmware (which you're forced to trust)
chose, via some policy you may be unaware of, to trust the booted
kernel.
You are currently using some of those interfaces for measuring to produce
a notionally 'trusted' initial loaded environment.
Correct me if I am wrong but your starting point is I have a chain of
measurement as far as the kernel I load. Without that I can just go into
grub and 0wn you.
In my use case. But not all implementations will be measuring things -
they can assert that the kernel is trustworthy through some other
mechanism. This genuinely is about trust, not measurement.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 19:24:55 + Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote: The fact that you keep saying measured really does make me suspect that you misunderstand the problem. There's no measurement involved, there's simply an assertion that the firmware (which you're forced to trust) chose, via some policy you may be unaware of, to trust the booted kernel. As an example, imagine a platform with the bootloader and kernel on read-only media. The platform can assert that the kernel is trusted even if there's no measurement of the kernel. Only if you have a secure signed path through the controller firmware and physical security of the hardware. If not I can reprogram your BIOS, your GPU firmware, your USB stick or your CD-ROM controller to lie. Anything must either be measurable or tamperproof from within the system itself (or both). So a physically write protected ROM bootloader loading a kernel and initrd from that same physically protected ROM is secure, but your average CD-ROM drive is not. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 21:58 +, One Thousand Gnomes wrote: On Fri, 14 Mar 2014 19:24:55 + Matthew Garrett matthew.garr...@nebula.com wrote: As an example, imagine a platform with the bootloader and kernel on read-only media. The platform can assert that the kernel is trusted even if there's no measurement of the kernel. Only if you have a secure signed path through the controller firmware and physical security of the hardware. If not I can reprogram your BIOS, your GPU firmware, your USB stick or your CD-ROM controller to lie. Sure, and then the trust that the firmware placed in the kernel would be misplaced. You can subvert Secure Boot with an SPI flasher, just as you can subvert selinux with a firewire dongle. Those attacks are outside the threat model. If you're in a situation where you have to care about threats outside that threat model then you need to choose a more appropriate solution. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 21:56:33 + Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote: In your particularly implementation maybe you've got a weak setup where you don't measure down to your initrd. That's a *flaw* in your implementation. Don't inflict your limitations on others or on the future. EFI is only one (and not a very strong one at that) implementation of a 'secure' boot chain. A lot of other systems can not only propogate measurement and security assertions into their initrd they can propogate them into their rootfs (yes upgrades are .. exciting, but these kinds of users will live with that pain). Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. Even in EFI you can make your kernel or loader check the initrd signature and the rootfs signature if you want. Except the initramfs gets built at kernel install time. Implementation detail for your use case. Correct me if I am wrong but your starting point is I have a chain of measurement as far as the kernel I load. Without that I can just go into grub and 0wn you. In my use case. But not all implementations will be measuring things - they can assert that the kernel is trustworthy through some other mechanism. This genuinely is about trust, not measurement. The assertion you attempt to achieve is I believe No ring 0 code is executed directly or indirectly that is not measured Some of your measuring is EFI boot, some is module signing and then you must impose a security model as well. It's a measurement problem if you ask what the rule is - yes ? Getting there is not just a measurement problem but your intended result is a measurement based rule ? Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: On Fri, 14 Mar 2014 21:56:33 + Matthew Garrett matthew.garr...@nebula.com wrote: Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. The general problem includes having to support this even without an selinux policy. Even in EFI you can make your kernel or loader check the initrd signature and the rootfs signature if you want. Except the initramfs gets built at kernel install time. Implementation detail for your use case. And one that's not going to change, so the general problem includes not relying on a signed initramfs. Correct me if I am wrong but your starting point is I have a chain of measurement as far as the kernel I load. Without that I can just go into grub and 0wn you. In my use case. But not all implementations will be measuring things - they can assert that the kernel is trustworthy through some other mechanism. This genuinely is about trust, not measurement. The assertion you attempt to achieve is I believe No ring 0 code is executed directly or indirectly that is not measured No. As I keep pointing out, not all code is measured. The firmware is not required to measure itself. A particular implementation may skip measuring the kernel because it can attest to its trustworthyness in some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 14 Mar 2014 22:15:45 + Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote: On Fri, 14 Mar 2014 21:56:33 + Matthew Garrett matthew.garr...@nebula.com wrote: Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. The general problem includes having to support this even without an selinux policy. Yes. No dispute about that. But equally the general solution should allow for it. And one that's not going to change, so the general problem includes not relying on a signed initramfs. Likewise some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. See How to Bypass Verified Boot Security in Chromium OS 8) And it attests the trustworthiness of the filesystem by measuring it. If you have a measurement of object X that states it is unchanged then you have a valid measurement of any subset of object X for which the same assertion is proven. In this case since you know all the bits in the root fs are as before, so you know all the bits in the module are as before And how do you know all the bits in the root fs are as before, because you have a set of measurements (hashes) on partition 12. At the end of the day you end up with a chain of measurements from a trusted thing you deep immutable. If your chain has gaps you have holes (see above). So ChromeOS loads *measured* kernel modules. It just did the measuring differently to the signed module code. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-03-14 at 22:31 +, One Thousand Gnomes wrote: On Fri, 14 Mar 2014 22:15:45 + Matthew Garrett matthew.garr...@nebula.com wrote: The general problem includes having to support this even without an selinux policy. Yes. No dispute about that. But equally the general solution should allow for it. Well, sure. The current implementation doesn't conflict with selinux in any way. some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. See How to Bypass Verified Boot Security in Chromium OS 8) And it attests the trustworthiness of the filesystem by measuring it. If you have a measurement of object X that states it is unchanged then you have a valid measurement of any subset of object X for which the same assertion is proven. In this case since you know all the bits in the root fs are as before, so you know all the bits in the module are as before You may attest to the trustworthiness of a filesystem by measuring it, but you may also attest to it via some other means - for instance, it's read-only and stored on media that requires physical presence to modify. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote: Signed userspace is not a requirement, and therefore any solution that relies on a signed initrd is inadequate. There are use cases that require verification of the initrd and other levels. This isn't one of them. The job of the kernel is to solve the general problem. There are lots of people who happen to care about verification beyond the kernel so it shouldn't be ignored. And they can do do things like load trusted SELinux rulesets even if you can't support it in your environment. This is really a question about goals and trust models. Alan is arguing that we should support trust models and goals which go far beyond the goals and trust model of the UEFI Forum. Matthew is, I think, trying to make the argument that his patches fulfill the goals that are needed so we can boot Linux distribution kernels on UEFI secure boot machines without worrying about Microsoft deciding to revoke keys so that Red Hat or SuSE will no longer be able to be bootable on desktops that are certified for Windows 8. And while we might want to improve the framework to support other trust models later on, supporting distro kernels on Windows 8 certified PC's is important enough that we should let these patches into mainline. Is that a fair summary of the two viewpoints? Personally, I think that we are fortunate that Windows 8 has been enough of a train wreck that huge numbers of users have been taking Windows 8 systems and upgrading them to Windows 7, and hence the need for Distro kernels that can boot on fully locked down Windows 8 PC's. But at some point, whether it is a few years or a decade later (if Windows 7 lives on as long as XP :-), Windows 7 will be EOL'ed, and even before that, UEFI secure boot will be enabled by default. Right now, even though Lenovo laptops are shipping with Windows 8. UEFI secure boot is not made mandatory (although it is on enough to brick the laptop when it runs into bugs wwith the UEFI BIOS code, sigh). But sooner or later, UEFI secure boot will be on by default, and then if Linux distros don't have kernels where the installer can be run without needing to twiddle BIOS settings, it might make it harder for the Year of the Desktop to come about. So as far as the narrow question of whether we should accept these patches, I think it's a good thing. Personally, I'm always going to be disabling UEFI secure boot (even if it doesn't brick my laptop), because for me, the security guarantees it provides isn't worth it. But there will be people who want to be able to install Linux on Windows 8 certified PC's without tweaking BIOS settings, so merging the UEFI secure boot is a good thing, so long as those of use who don't want to have anything to do with UEFI secure boot can disable it. Regards, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
So as far as the narrow question of whether we should accept these patches, I think it's a good thing. Personally, I'm always going to be disabling UEFI secure boot (even if it doesn't brick my laptop), because for me, the security guarantees it provides isn't worth it. But there will be people who want to be able to install Linux on Windows 8 certified PC's without tweaking BIOS settings, so merging the UEFI secure boot is a good thing, so long as those of use who don't want to have anything to do with UEFI secure boot can disable it. I definitely think we want the feature and there are a lot of non UEFI reasons for this (eg running trusted_kernel() virtual namespaces). I have three specific issues 1. The implementation is a mess in part because it propogates more policy all over the place that should be separated. Root cause capable() mixes policy and activity. Fix suggested in my previous emails (and offer to do the work) 2. It's likely to lead to more bugs and errors because of the way it has been done and it doesn't break old code that gets added without considering the issue. It fails insecure which is bad. Fixed by doing what I suggested (and offered to do) 3. For things like module options we should be white not blacklisting 'bad' ones. I've offered to go and fix up the capability stuff - I'm just waiting for Matthew to actually confirm the question I specifically asked him - does this solve that bit of his problem. If it does great, I'll go and sort the capability bits out so we can keep the policy in the right place and we don't have the kernel festooned with !trusted_kernel() everywhere. There is a question of completeness but its very clear we get there with a combination of two things - whitelisting so we catch stuff we missed rather than leave holes, and just accepting the reality that it'll take a few kernels once its upstream until we get them all. I care about security, we should do the job properly. We have a further magnitude shift in security needs coming that's going to be at least equivalent to the scale of shift between the old 'university, everyone is nice' internet and today. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 23:21 +, One Thousand Gnomes wrote: > On Thu, 13 Mar 2014 21:30:48 + > Matthew Garrett wrote: > > > On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote: > > > > > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, > > > trivially and in a fashion well known and documented. > > > > How? > > You want a list... there are load of places all over the kernel that have > assumptions that RAWIO = safe from the boringly mundane like MSR access > to the more obscure driver "this is RAWIO trust the user" cases of which > there are plenty. Have you actually looked at these patches? I've looked at every case of RAWIO in the kernel. For cases that are hardware specific and tied to fairly old hardware, I've ignored them. For cases which provide an obvious mechanism for exploitation, I've added an additional check. For cases where I can't see a reasonable mechanism for executing arbitrary code in the kernel, I've done nothing. If you have specific examples of processes with CAP_SYS_RAWIO being able to execute arbitrary code in the kernel even with this patchset applied, please, give them. >You can even avoid the userspace issues with a small amount of >checking. If you don't want to touch capability sets then make the >default behaviour for capable(x) in fact be > >capable(x & ~secure_forbidden) > >for a measured kernel and add a > >capable_always() > >for the cases you want to not break. We could do that, but now the behaviour of the patchset is far less obvious. capable(CAP_SYS_RAWIO) now means something different to every other use of capable(), and we still need get_trusted_kernel() calls for cases where the checks have nothing to do with processes and so capabilities can't be used. It still involves auditing every use of CAP_SYS_RAWIO. In fact, in some cases we need to *add* CAP_SYS_RAWIO checks - which, again, breaks userspace. > As for mem= and exactmap, it has nothing to do with /dev/mem and > everything to do with giving the kernel a memory map where some of the > space it thinks is RAM is in fact devices, rom, space etc. If the kernel > is given a false memory map it will misbehave. Exploitably - well given > the kind of things people have achieved in the past - quite possibly. Sure. That's a worthwhile thing to fix, and it's something that dropping CAP_SYS_RAWIO would do nothing to help you with. > If you are not prepared to do the job right, then I don't think it > belongs upstream. Let's do it right, and if we have to tweak a few bits > of userspace to make them work in measured mode (but without breaking > anything in normal modes) then it's worth doing the job properly. We can do this without unnecessarily breaking any userspace. We just can't do it by fiddling with capabilities. > I don't think we need to break any userspace for "normal" mode to do > this. Userspace in measured mode is going to change anyway. It already > has just for things like module signing. This has been discussed at length. Nobody who's actually spent time working on the problem wants to use capabilities. CAP_SYS_RAWIO is not semantically identical to the trusted kernel bit. Trying to make them semantically identical will break existing userspace. > (As an aside you may also then want to think about whether you allow > measured userspace elements that secure_forbidden is considered to be 0 > for so you can sign userspace apps that are allowed to do RAWIO) I'd be amazed if any of the applications that need RAWIO have had any kind of meaningful security audit, with the possible exception of X (and then we'd need to add support for signed X modules and sign all the DDXes and seriously just no). I've no objection to someone doing that work (and Vivek did a pile of it when looking at implementing kexec via signed userspace), but I don't see any real use cases - pretty much everyone using bits of RAWIO that are gated in the trusted kernel case should be using a real kernel interface instead. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 21:30:48 + Matthew Garrett wrote: > On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote: > > > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, > > trivially and in a fashion well known and documented. > > How? You want a list... there are load of places all over the kernel that have assumptions that RAWIO = safe from the boringly mundane like MSR access to the more obscure driver "this is RAWIO trust the user" cases of which there are plenty. If you are going to do something "secure" then do it *right* otherwise you are not actually implementing anything, just making fake security noises. SELinux required user space changes, fiddle with CAP_SYS_RAWIO will need userspace changes IFF you want to run 'secure' mode. That I think is acceptable. You can even avoid the userspace issues with a small amount of checking. If you don't want to touch capability sets then make the default behaviour for capable(x) in fact be capable(x & ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. As for mem= and exactmap, it has nothing to do with /dev/mem and everything to do with giving the kernel a memory map where some of the space it thinks is RAM is in fact devices, rom, space etc. If the kernel is given a false memory map it will misbehave. Exploitably - well given the kind of things people have achieved in the past - quite possibly. If you are not prepared to do the job right, then I don't think it belongs upstream. Let's do it right, and if we have to tweak a few bits of userspace to make them work in measured mode (but without breaking anything in normal modes) then it's worth doing the job properly. I don't think we need to break any userspace for "normal" mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. (As an aside you may also then want to think about whether you allow measured userspace elements that secure_forbidden is considered to be 0 for so you can sign userspace apps that are allowed to do RAWIO) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 14:28 -0700, H. Peter Anvin wrote:
> On 03/13/2014 02:24 PM, One Thousand Gnomes wrote:
> >
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
> >
>
> ... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become
> redundant.
We can only drop CAP_SYS_RAWIO if we change a bunch of the existing
CAP_SYS_RAWIO checks to something else. How do we do that without
breaking existing userspace?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 21:26 +, One Thousand Gnomes wrote:
> > On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
> > functionality - firmware loading and the fibmap ioctl are probably the
> > most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
> > userspace expectations, so we're kind of stuck there.
>
> Actually I know how to describe the problem better.
>
> Whitelist v Blacklist.
>
> Going around adding extra cases for CAP_SYS_RAWIO is a fails insecure
> model. Going around adding CAP_SYS_RAWIO || CAP_SYS_RAWIO_SEC is a 'fails
> secure' case.
We've already been through this. We can't add new capabilities. It
breaks existing userspace.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
> If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> trivially and in a fashion well known and documented.
How?
> You've missed a few others too - mem= (especially with exactmap) for
> example.
/dev/mem access is restricted, so what would this buy you? The potential
to have the kernel hand over a region belonging to hardware in response
to a userspace allocation?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On 03/13/2014 02:24 PM, One Thousand Gnomes wrote: > > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, > trivially and in a fashion well known and documented. > ... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become redundant. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
> On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected > functionality - firmware loading and the fibmap ioctl are probably the > most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks > userspace expectations, so we're kind of stuck there. Actually I know how to describe the problem better. Whitelist v Blacklist. Going around adding extra cases for CAP_SYS_RAWIO is a fails insecure model. Going around adding CAP_SYS_RAWIO || CAP_SYS_RAWIO_SEC is a 'fails secure' case. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 15:59:24 + Matthew Garrett wrote: > On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote: > > > I'll take it, but there's unanswered review feedback (your response to the > > first question), and Alan raised some doubts about the patches which I'm > > not sure have been resolved. > > The remaining opens seem to be CAP_SYS_RAWIO and firmware signing? > Ironically, disabling CAP_SYS_RAWIO disables firmware loading… > > The problem with CAP_SYS_RAWIO is that its semantics were never > sufficiently well documented, and as a result it's a mixture of "This is > incredibly dangerous" and "We replaced a check for uid 0 with whichever > capability seemed to have the most appropriate name". I've gone through > all the uses of CAP_SYS_RAWIO and added additional checks to the generic > ones that seem appropriate. There's a couple of old drivers that use it > to gate access to features that potentially allow arbitrary DMA and it > might be worth cleaning those up, but the only general case I haven't > modified is the ability to send arbitrary SCSI commands from userspace. > My understanding is that endpoints aren't going to be able to DMA to > arbitrary addresses, so that doesn't seem like a problem. > > On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected > functionality - firmware loading and the fibmap ioctl are probably the > most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks > userspace expectations, so we're kind of stuck there. If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. So if that isn't sufficient then we need to sort CAP_foo out first. You've missed a few others too - mem= (especially with exactmap) for example. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote: > I'll take it, but there's unanswered review feedback (your response to the > first question), and Alan raised some doubts about the patches which I'm > not sure have been resolved. The remaining opens seem to be CAP_SYS_RAWIO and firmware signing? Ironically, disabling CAP_SYS_RAWIO disables firmware loading… The problem with CAP_SYS_RAWIO is that its semantics were never sufficiently well documented, and as a result it's a mixture of "This is incredibly dangerous" and "We replaced a check for uid 0 with whichever capability seemed to have the most appropriate name". I've gone through all the uses of CAP_SYS_RAWIO and added additional checks to the generic ones that seem appropriate. There's a couple of old drivers that use it to gate access to features that potentially allow arbitrary DMA and it might be worth cleaning those up, but the only general case I haven't modified is the ability to send arbitrary SCSI commands from userspace. My understanding is that endpoints aren't going to be able to DMA to arbitrary addresses, so that doesn't seem like a problem. On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected functionality - firmware loading and the fibmap ioctl are probably the most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks userspace expectations, so we're kind of stuck there. As for signed firmware, I'm looking forward to Kees' work on that. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On 03/13/2014 03:12 AM, One Thousand Gnomes wrote: > > I would prefer it did the revocation of CAP_SYS_RAWIO or at least > documented the absolute requirement. > Seconded. This has been my opinion, raised over and over and over again. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 20:33:06 +1100 (EST) James Morris wrote: > On Wed, 12 Mar 2014, Kees Cook wrote: > > > On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett > > wrote: > > > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: > > > > > >> Ok, which tree should take this? I'm happy to, although most of it is > > >> outside security/ . > > > > > > Should I be looking for someone else to take them instead? :) > > > > Andrew, is this series[1] something you'd be okay taking? It touches > > many different areas, so you might be best for it. > > I'll take it, but there's unanswered review feedback (your response to the > first question), and Alan raised some doubts about the patches which I'm > not sure have been resolved. I have a series of doubts about their completeness which didn't get any answer at all, and one on the misleading use of the term "secure" as opposed to "measured" 8) I don't think it's reasonable to have a policy of refusing them until they cover all cases. It's not like it can be dropped into staging and refined. So other than the usual moan about people naming things "security" being like putting "i-" and "e-" on the front of stuff to make it sound cool when it isn't what it says I'm fine 8) I would prefer it did the revocation of CAP_SYS_RAWIO or at least documented the absolute requirement. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, 12 Mar 2014, Kees Cook wrote: > On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett > wrote: > > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: > > > >> Ok, which tree should take this? I'm happy to, although most of it is > >> outside security/ . > > > > Should I be looking for someone else to take them instead? :) > > Andrew, is this series[1] something you'd be okay taking? It touches > many different areas, so you might be best for it. I'll take it, but there's unanswered review feedback (your response to the first question), and Alan raised some doubts about the patches which I'm not sure have been resolved. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett wrote: > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: > >> Ok, which tree should take this? I'm happy to, although most of it is >> outside security/ . > > Should I be looking for someone else to take them instead? :) Andrew, is this series[1] something you'd be okay taking? It touches many different areas, so you might be best for it. -Kees [1] https://lkml.org/lkml/2014/2/26/811 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: Ok, which tree should take this? I'm happy to, although most of it is outside security/ . Should I be looking for someone else to take them instead? :) Andrew, is this series[1] something you'd be okay taking? It touches many different areas, so you might be best for it. -Kees [1] https://lkml.org/lkml/2014/2/26/811 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, 12 Mar 2014, Kees Cook wrote: On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: Ok, which tree should take this? I'm happy to, although most of it is outside security/ . Should I be looking for someone else to take them instead? :) Andrew, is this series[1] something you'd be okay taking? It touches many different areas, so you might be best for it. I'll take it, but there's unanswered review feedback (your response to the first question), and Alan raised some doubts about the patches which I'm not sure have been resolved. -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 20:33:06 +1100 (EST) James Morris jmor...@namei.org wrote: On Wed, 12 Mar 2014, Kees Cook wrote: On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett matthew.garr...@nebula.com wrote: On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: Ok, which tree should take this? I'm happy to, although most of it is outside security/ . Should I be looking for someone else to take them instead? :) Andrew, is this series[1] something you'd be okay taking? It touches many different areas, so you might be best for it. I'll take it, but there's unanswered review feedback (your response to the first question), and Alan raised some doubts about the patches which I'm not sure have been resolved. I have a series of doubts about their completeness which didn't get any answer at all, and one on the misleading use of the term secure as opposed to measured 8) I don't think it's reasonable to have a policy of refusing them until they cover all cases. It's not like it can be dropped into staging and refined. So other than the usual moan about people naming things security being like putting i- and e- on the front of stuff to make it sound cool when it isn't what it says I'm fine 8) I would prefer it did the revocation of CAP_SYS_RAWIO or at least documented the absolute requirement. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On 03/13/2014 03:12 AM, One Thousand Gnomes wrote: I would prefer it did the revocation of CAP_SYS_RAWIO or at least documented the absolute requirement. Seconded. This has been my opinion, raised over and over and over again. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote: I'll take it, but there's unanswered review feedback (your response to the first question), and Alan raised some doubts about the patches which I'm not sure have been resolved. The remaining opens seem to be CAP_SYS_RAWIO and firmware signing? Ironically, disabling CAP_SYS_RAWIO disables firmware loading… The problem with CAP_SYS_RAWIO is that its semantics were never sufficiently well documented, and as a result it's a mixture of This is incredibly dangerous and We replaced a check for uid 0 with whichever capability seemed to have the most appropriate name. I've gone through all the uses of CAP_SYS_RAWIO and added additional checks to the generic ones that seem appropriate. There's a couple of old drivers that use it to gate access to features that potentially allow arbitrary DMA and it might be worth cleaning those up, but the only general case I haven't modified is the ability to send arbitrary SCSI commands from userspace. My understanding is that endpoints aren't going to be able to DMA to arbitrary addresses, so that doesn't seem like a problem. On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected functionality - firmware loading and the fibmap ioctl are probably the most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks userspace expectations, so we're kind of stuck there. As for signed firmware, I'm looking forward to Kees' work on that. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 15:59:24 + Matthew Garrett matthew.garr...@nebula.com wrote: On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote: I'll take it, but there's unanswered review feedback (your response to the first question), and Alan raised some doubts about the patches which I'm not sure have been resolved. The remaining opens seem to be CAP_SYS_RAWIO and firmware signing? Ironically, disabling CAP_SYS_RAWIO disables firmware loading… The problem with CAP_SYS_RAWIO is that its semantics were never sufficiently well documented, and as a result it's a mixture of This is incredibly dangerous and We replaced a check for uid 0 with whichever capability seemed to have the most appropriate name. I've gone through all the uses of CAP_SYS_RAWIO and added additional checks to the generic ones that seem appropriate. There's a couple of old drivers that use it to gate access to features that potentially allow arbitrary DMA and it might be worth cleaning those up, but the only general case I haven't modified is the ability to send arbitrary SCSI commands from userspace. My understanding is that endpoints aren't going to be able to DMA to arbitrary addresses, so that doesn't seem like a problem. On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected functionality - firmware loading and the fibmap ioctl are probably the most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks userspace expectations, so we're kind of stuck there. If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. So if that isn't sufficient then we need to sort CAP_foo out first. You've missed a few others too - mem= (especially with exactmap) for example. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected functionality - firmware loading and the fibmap ioctl are probably the most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks userspace expectations, so we're kind of stuck there. Actually I know how to describe the problem better. Whitelist v Blacklist. Going around adding extra cases for CAP_SYS_RAWIO is a fails insecure model. Going around adding CAP_SYS_RAWIO || CAP_SYS_RAWIO_SEC is a 'fails secure' case. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On 03/13/2014 02:24 PM, One Thousand Gnomes wrote: If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. ... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become redundant. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
trivially and in a fashion well known and documented.
How?
You've missed a few others too - mem= (especially with exactmap) for
example.
/dev/mem access is restricted, so what would this buy you? The potential
to have the kernel hand over a region belonging to hardware in response
to a userspace allocation?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 21:26 +, One Thousand Gnomes wrote:
On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
functionality - firmware loading and the fibmap ioctl are probably the
most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
userspace expectations, so we're kind of stuck there.
Actually I know how to describe the problem better.
Whitelist v Blacklist.
Going around adding extra cases for CAP_SYS_RAWIO is a fails insecure
model. Going around adding CAP_SYS_RAWIO || CAP_SYS_RAWIO_SEC is a 'fails
secure' case.
We've already been through this. We can't add new capabilities. It
breaks existing userspace.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 14:28 -0700, H. Peter Anvin wrote:
On 03/13/2014 02:24 PM, One Thousand Gnomes wrote:
If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
trivially and in a fashion well known and documented.
... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become
redundant.
We can only drop CAP_SYS_RAWIO if we change a bunch of the existing
CAP_SYS_RAWIO checks to something else. How do we do that without
breaking existing userspace?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 13 Mar 2014 21:30:48 + Matthew Garrett matthew.garr...@nebula.com wrote: On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote: If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. How? You want a list... there are load of places all over the kernel that have assumptions that RAWIO = safe from the boringly mundane like MSR access to the more obscure driver this is RAWIO trust the user cases of which there are plenty. If you are going to do something secure then do it *right* otherwise you are not actually implementing anything, just making fake security noises. SELinux required user space changes, fiddle with CAP_SYS_RAWIO will need userspace changes IFF you want to run 'secure' mode. That I think is acceptable. You can even avoid the userspace issues with a small amount of checking. If you don't want to touch capability sets then make the default behaviour for capable(x) in fact be capable(x ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. As for mem= and exactmap, it has nothing to do with /dev/mem and everything to do with giving the kernel a memory map where some of the space it thinks is RAM is in fact devices, rom, space etc. If the kernel is given a false memory map it will misbehave. Exploitably - well given the kind of things people have achieved in the past - quite possibly. If you are not prepared to do the job right, then I don't think it belongs upstream. Let's do it right, and if we have to tweak a few bits of userspace to make them work in measured mode (but without breaking anything in normal modes) then it's worth doing the job properly. I don't think we need to break any userspace for normal mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. (As an aside you may also then want to think about whether you allow measured userspace elements that secure_forbidden is considered to be 0 for so you can sign userspace apps that are allowed to do RAWIO) Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 23:21 +, One Thousand Gnomes wrote: On Thu, 13 Mar 2014 21:30:48 + Matthew Garrett matthew.garr...@nebula.com wrote: On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote: If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace, trivially and in a fashion well known and documented. How? You want a list... there are load of places all over the kernel that have assumptions that RAWIO = safe from the boringly mundane like MSR access to the more obscure driver this is RAWIO trust the user cases of which there are plenty. Have you actually looked at these patches? I've looked at every case of RAWIO in the kernel. For cases that are hardware specific and tied to fairly old hardware, I've ignored them. For cases which provide an obvious mechanism for exploitation, I've added an additional check. For cases where I can't see a reasonable mechanism for executing arbitrary code in the kernel, I've done nothing. If you have specific examples of processes with CAP_SYS_RAWIO being able to execute arbitrary code in the kernel even with this patchset applied, please, give them. You can even avoid the userspace issues with a small amount of checking. If you don't want to touch capability sets then make the default behaviour for capable(x) in fact be capable(x ~secure_forbidden) for a measured kernel and add a capable_always() for the cases you want to not break. We could do that, but now the behaviour of the patchset is far less obvious. capable(CAP_SYS_RAWIO) now means something different to every other use of capable(), and we still need get_trusted_kernel() calls for cases where the checks have nothing to do with processes and so capabilities can't be used. It still involves auditing every use of CAP_SYS_RAWIO. In fact, in some cases we need to *add* CAP_SYS_RAWIO checks - which, again, breaks userspace. As for mem= and exactmap, it has nothing to do with /dev/mem and everything to do with giving the kernel a memory map where some of the space it thinks is RAM is in fact devices, rom, space etc. If the kernel is given a false memory map it will misbehave. Exploitably - well given the kind of things people have achieved in the past - quite possibly. Sure. That's a worthwhile thing to fix, and it's something that dropping CAP_SYS_RAWIO would do nothing to help you with. If you are not prepared to do the job right, then I don't think it belongs upstream. Let's do it right, and if we have to tweak a few bits of userspace to make them work in measured mode (but without breaking anything in normal modes) then it's worth doing the job properly. We can do this without unnecessarily breaking any userspace. We just can't do it by fiddling with capabilities. I don't think we need to break any userspace for normal mode to do this. Userspace in measured mode is going to change anyway. It already has just for things like module signing. This has been discussed at length. Nobody who's actually spent time working on the problem wants to use capabilities. CAP_SYS_RAWIO is not semantically identical to the trusted kernel bit. Trying to make them semantically identical will break existing userspace. (As an aside you may also then want to think about whether you allow measured userspace elements that secure_forbidden is considered to be 0 for so you can sign userspace apps that are allowed to do RAWIO) I'd be amazed if any of the applications that need RAWIO have had any kind of meaningful security audit, with the possible exception of X (and then we'd need to add support for signed X modules and sign all the DDXes and seriously just no). I've no objection to someone doing that work (and Vivek did a pile of it when looking at implementing kexec via signed userspace), but I don't see any real use cases - pretty much everyone using bits of RAWIO that are gated in the trusted kernel case should be using a real kernel interface instead. -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: > Ok, which tree should take this? I'm happy to, although most of it is > outside security/ . Should I be looking for someone else to take them instead? :) -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: Ok, which tree should take this? I'm happy to, although most of it is outside security/ . Should I be looking for someone else to take them instead? :) -- Matthew Garrett matthew.garr...@nebula.com
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 2:11 PM, Josh Boyer wrote: > On Thu, Feb 27, 2014 at 2:07 PM, Greg KH wrote: >> On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: >>> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett >>> wrote: >>> > The conclusion we came to at Plumbers was that this patchset was basically >>> > fine but that Linus hated the name "securelevel" more than I hate pickled >>> > herring, so after thinking about this for a few months I've come up with >>> > "Trusted Kernel". This flag indicates that the kernel is, via some >>> > external mechanism, trusted and should behave that way. If firmware has >>> > some way to verify the kernel, it can pass that information on. If >>> > userspace >>> > has some way to verify the kernel, it can set the flag itself. However, >>> > userspace should not attempt to use the flag as a means to verify that the >>> > kernel was trusted - untrusted userspace could have set it on an untrusted >>> > kernel, but by the same metric an untrusted kernel could just set it >>> > itself. >>> >>> FWIW, I've been running a kernel using this patchset in place of the >>> patchset Fedora typically carries for this purpose for a bit. Things >>> appear to be working as expected and the protections remain the same. >>> >>> It would be really nice to get this set of patches in so some of the >>> other patches that depend on them can start being pushed as well. >> >> What other patches depend on this series? Why aren't they also in this >> series? > > The patches we have to import certificates from the UEFI db and dbx > vars, and MokListRT and apply them to signed module verification. > Looking at them closely, there are pieces that could be sent now as > they are slightly orthogonal to what this patchset is doing, which is > probably why they aren't in this patchset to begin with. I'll have to > figure out which of those actually depend on anything in Matthew's > series. OK, I figured it out. I have a patch that adds an EFI_SECURE_BOOT x86_efi_facility bit, and that is used in the later patches where applicable. The patch that adds it depends on patch 12 in Matthew's series. There are a few patches that are mostly stand-alone and I'll try and get those sent out soon. They're a mix of things from David Howells and myself, and should probably go through the security tree. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 2:11 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Feb 27, 2014 at 2:07 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett matthew.garr...@nebula.com wrote: The conclusion we came to at Plumbers was that this patchset was basically fine but that Linus hated the name securelevel more than I hate pickled herring, so after thinking about this for a few months I've come up with Trusted Kernel. This flag indicates that the kernel is, via some external mechanism, trusted and should behave that way. If firmware has some way to verify the kernel, it can pass that information on. If userspace has some way to verify the kernel, it can set the flag itself. However, userspace should not attempt to use the flag as a means to verify that the kernel was trusted - untrusted userspace could have set it on an untrusted kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. What other patches depend on this series? Why aren't they also in this series? The patches we have to import certificates from the UEFI db and dbx vars, and MokListRT and apply them to signed module verification. Looking at them closely, there are pieces that could be sent now as they are slightly orthogonal to what this patchset is doing, which is probably why they aren't in this patchset to begin with. I'll have to figure out which of those actually depend on anything in Matthew's series. OK, I figured it out. I have a patch that adds an EFI_SECURE_BOOT x86_efi_facility bit, and that is used in the later patches where applicable. The patch that adds it depends on patch 12 in Matthew's series. There are a few patches that are mostly stand-alone and I'll try and get those sent out soon. They're a mix of things from David Howells and myself, and should probably go through the security tree. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: > Ok, which tree should take this? I'm happy to, although most of it is > outside security/ . Security might make the most sense - I don't think any of the additional restrictions (beyond kexec, and I think we've hashed that argument out now) are terribly controversial. -- Matthew Garrett
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 27 Feb 2014, Josh Boyer wrote: > On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett > wrote: > > The conclusion we came to at Plumbers was that this patchset was basically > > fine but that Linus hated the name "securelevel" more than I hate pickled > > herring, so after thinking about this for a few months I've come up with > > "Trusted Kernel". This flag indicates that the kernel is, via some > > external mechanism, trusted and should behave that way. If firmware has > > some way to verify the kernel, it can pass that information on. If userspace > > has some way to verify the kernel, it can set the flag itself. However, > > userspace should not attempt to use the flag as a means to verify that the > > kernel was trusted - untrusted userspace could have set it on an untrusted > > kernel, but by the same metric an untrusted kernel could just set it itself. > > FWIW, I've been running a kernel using this patchset in place of the > patchset Fedora typically carries for this purpose for a bit. Things > appear to be working as expected and the protections remain the same. > > It would be really nice to get this set of patches in so some of the > other patches that depend on them can start being pushed as well. Ok, which tree should take this? I'm happy to, although most of it is outside security/ . -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 2:07 PM, Greg KH wrote: > On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: >> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett >> wrote: >> > The conclusion we came to at Plumbers was that this patchset was basically >> > fine but that Linus hated the name "securelevel" more than I hate pickled >> > herring, so after thinking about this for a few months I've come up with >> > "Trusted Kernel". This flag indicates that the kernel is, via some >> > external mechanism, trusted and should behave that way. If firmware has >> > some way to verify the kernel, it can pass that information on. If >> > userspace >> > has some way to verify the kernel, it can set the flag itself. However, >> > userspace should not attempt to use the flag as a means to verify that the >> > kernel was trusted - untrusted userspace could have set it on an untrusted >> > kernel, but by the same metric an untrusted kernel could just set it >> > itself. >> >> FWIW, I've been running a kernel using this patchset in place of the >> patchset Fedora typically carries for this purpose for a bit. Things >> appear to be working as expected and the protections remain the same. >> >> It would be really nice to get this set of patches in so some of the >> other patches that depend on them can start being pushed as well. > > What other patches depend on this series? Why aren't they also in this > series? The patches we have to import certificates from the UEFI db and dbx vars, and MokListRT and apply them to signed module verification. Looking at them closely, there are pieces that could be sent now as they are slightly orthogonal to what this patchset is doing, which is probably why they aren't in this patchset to begin with. I'll have to figure out which of those actually depend on anything in Matthew's series. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: > On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett > wrote: > > The conclusion we came to at Plumbers was that this patchset was basically > > fine but that Linus hated the name "securelevel" more than I hate pickled > > herring, so after thinking about this for a few months I've come up with > > "Trusted Kernel". This flag indicates that the kernel is, via some > > external mechanism, trusted and should behave that way. If firmware has > > some way to verify the kernel, it can pass that information on. If userspace > > has some way to verify the kernel, it can set the flag itself. However, > > userspace should not attempt to use the flag as a means to verify that the > > kernel was trusted - untrusted userspace could have set it on an untrusted > > kernel, but by the same metric an untrusted kernel could just set it itself. > > FWIW, I've been running a kernel using this patchset in place of the > patchset Fedora typically carries for this purpose for a bit. Things > appear to be working as expected and the protections remain the same. > > It would be really nice to get this set of patches in so some of the > other patches that depend on them can start being pushed as well. What other patches depend on this series? Why aren't they also in this series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett wrote: > The conclusion we came to at Plumbers was that this patchset was basically > fine but that Linus hated the name "securelevel" more than I hate pickled > herring, so after thinking about this for a few months I've come up with > "Trusted Kernel". This flag indicates that the kernel is, via some > external mechanism, trusted and should behave that way. If firmware has > some way to verify the kernel, it can pass that information on. If userspace > has some way to verify the kernel, it can set the flag itself. However, > userspace should not attempt to use the flag as a means to verify that the > kernel was trusted - untrusted userspace could have set it on an untrusted > kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett matthew.garr...@nebula.com wrote: The conclusion we came to at Plumbers was that this patchset was basically fine but that Linus hated the name securelevel more than I hate pickled herring, so after thinking about this for a few months I've come up with Trusted Kernel. This flag indicates that the kernel is, via some external mechanism, trusted and should behave that way. If firmware has some way to verify the kernel, it can pass that information on. If userspace has some way to verify the kernel, it can set the flag itself. However, userspace should not attempt to use the flag as a means to verify that the kernel was trusted - untrusted userspace could have set it on an untrusted kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett matthew.garr...@nebula.com wrote: The conclusion we came to at Plumbers was that this patchset was basically fine but that Linus hated the name securelevel more than I hate pickled herring, so after thinking about this for a few months I've come up with Trusted Kernel. This flag indicates that the kernel is, via some external mechanism, trusted and should behave that way. If firmware has some way to verify the kernel, it can pass that information on. If userspace has some way to verify the kernel, it can set the flag itself. However, userspace should not attempt to use the flag as a means to verify that the kernel was trusted - untrusted userspace could have set it on an untrusted kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. What other patches depend on this series? Why aren't they also in this series? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, Feb 27, 2014 at 2:07 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett matthew.garr...@nebula.com wrote: The conclusion we came to at Plumbers was that this patchset was basically fine but that Linus hated the name securelevel more than I hate pickled herring, so after thinking about this for a few months I've come up with Trusted Kernel. This flag indicates that the kernel is, via some external mechanism, trusted and should behave that way. If firmware has some way to verify the kernel, it can pass that information on. If userspace has some way to verify the kernel, it can set the flag itself. However, userspace should not attempt to use the flag as a means to verify that the kernel was trusted - untrusted userspace could have set it on an untrusted kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. What other patches depend on this series? Why aren't they also in this series? The patches we have to import certificates from the UEFI db and dbx vars, and MokListRT and apply them to signed module verification. Looking at them closely, there are pieces that could be sent now as they are slightly orthogonal to what this patchset is doing, which is probably why they aren't in this patchset to begin with. I'll have to figure out which of those actually depend on anything in Matthew's series. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 27 Feb 2014, Josh Boyer wrote: On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett matthew.garr...@nebula.com wrote: The conclusion we came to at Plumbers was that this patchset was basically fine but that Linus hated the name securelevel more than I hate pickled herring, so after thinking about this for a few months I've come up with Trusted Kernel. This flag indicates that the kernel is, via some external mechanism, trusted and should behave that way. If firmware has some way to verify the kernel, it can pass that information on. If userspace has some way to verify the kernel, it can set the flag itself. However, userspace should not attempt to use the flag as a means to verify that the kernel was trusted - untrusted userspace could have set it on an untrusted kernel, but by the same metric an untrusted kernel could just set it itself. FWIW, I've been running a kernel using this patchset in place of the patchset Fedora typically carries for this purpose for a bit. Things appear to be working as expected and the protections remain the same. It would be really nice to get this set of patches in so some of the other patches that depend on them can start being pushed as well. Ok, which tree should take this? I'm happy to, although most of it is outside security/ . -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trusted kernel patchset for Secure Boot lockdown
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote: Ok, which tree should take this? I'm happy to, although most of it is outside security/ . Security might make the most sense - I don't think any of the additional restrictions (beyond kexec, and I think we've hashed that argument out now) are terribly controversial. -- Matthew Garrett matthew.garr...@nebula.com
