Re: [PATCH 00/12] One more attempt at useful kernel lockdown
於 二，2013-09-10 於 18:26 +，Matthew Garrett 提到：
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
runtime firmware loader?
It'd be simple to do so, but so far the model appears to be that devices
that expect signed firmware enforce that themselves.
--
Matthew Garrett matthew.garr...@nebula.com
NrybXǧv^){.n+{y^nrzh Gh(階ݢjmzޖfh~m
Takashi has a implementation of firmware check:
[PATCH RFC v2 0/4] Add firmware signature file check
https://lkml.org/lkml/2012/11/8/343
Thanks
Joey Lee
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? It'd be simple to do so, but so far the model appears to be that devices that expect signed firmware enforce that themselves. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On 09/10/2013 11:26 AM, Matthew Garrett wrote: On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? It'd be simple to do so, but so far the model appears to be that devices that expect signed firmware enforce that themselves. Most devices do absolutely no verification on the firmware, and simply trust the driver. So signing firmware is probably critical. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, Sep 10, 2013 at 11:51 AM, gre...@linuxfoundation.org gre...@linuxfoundation.org wrote: On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote: On 09/10/2013 11:26 AM, Matthew Garrett wrote: On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? It'd be simple to do so, but so far the model appears to be that devices that expect signed firmware enforce that themselves. Most devices do absolutely no verification on the firmware, and simply trust the driver. So signing firmware is probably critical. How are you going to validate that the firmware is correct, given that it's just a blob living in the linux-firmware tree. If you sign it, what is that saying? In theory these blobs are traceable to a manufacturer. It's not really an indication that it's safe more than it's an indication that it hasn't been changed. But I haven't chased this very hard yet because of below... I'm with Matthew here, any device that needs/wants this, has their own built-in checking, nothing the kernel should do here. Especially given that no other os does this :) Yeah, it's impossible to handle since the way components do firmware updates is frequently exposed to userspace anyway. 3G modems that do firmware updates over the AT-command set, harddrives doing firmware updates over SCSI-generic commands, etc. Creating this barrier in the kernel is not a good solution; the component makers need to be doing the enforcement. :( -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote: On 09/10/2013 11:26 AM, Matthew Garrett wrote: On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? It'd be simple to do so, but so far the model appears to be that devices that expect signed firmware enforce that themselves. Most devices do absolutely no verification on the firmware, and simply trust the driver. So signing firmware is probably critical. How are you going to validate that the firmware is correct, given that it's just a blob living in the linux-firmware tree. If you sign it, what is that saying? I'm with Matthew here, any device that needs/wants this, has their own built-in checking, nothing the kernel should do here. Especially given that no other os does this :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, 10 Sep 2013, Kees Cook wrote: Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown On Tue, Sep 10, 2013 at 11:51 AM, gre...@linuxfoundation.org gre...@linuxfoundation.org wrote: On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote: On 09/10/2013 11:26 AM, Matthew Garrett wrote: On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: That's why modern systems require signed firmware updates. Linux doesn't. Is someone working on adding signature support to the runtime firmware loader? It'd be simple to do so, but so far the model appears to be that devices that expect signed firmware enforce that themselves. Most devices do absolutely no verification on the firmware, and simply trust the driver. So signing firmware is probably critical. How are you going to validate that the firmware is correct, given that it's just a blob living in the linux-firmware tree. If you sign it, what is that saying? In theory these blobs are traceable to a manufacturer. It's not really an indication that it's safe more than it's an indication that it hasn't been changed. But I haven't chased this very hard yet because of below... well, not if you are trying to defend against root breaking in to the machine. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On 09/10/2013 12:17 PM, David Lang wrote: In theory these blobs are traceable to a manufacturer. It's not really an indication that it's safe more than it's an indication that it hasn't been changed. But I haven't chased this very hard yet because of below... well, not if you are trying to defend against root breaking in to the machine. And we have at least some drivers where we even have the firmware in the Linux kernel tree, and thus aren't opaque blobs at all. I suspect we'll need, at some point, a way for vendors that aren't already doing signatures on their firmware in a device-specific way to do so in a kernel-supported way. The easiest (in terms of getting vendors to play along, not necessarily technically) might be a PGP signature (either inline or standalone) and have the public key as part of the driver? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On 09/10/2013 04:55 PM, Mimi Zohar wrote: What would the deliverables be from the hardware vendor and what tools would you expect them to need on their end? The package installer needs to not only install files, but file metadata as well. Elena Reshetova (Intel) has already added rpm hooks to write security xattrs. The next step, yet to be done, is to include and write the signatures as part of the rpm install process. That's a total non-option. There needs to be something that can be done even on a Windows box by a largely untrained release engineer if we're going to have a prayer of getting this supported. So, there is your answer why not. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, 2013-09-10 at 12:44 -0700, H. Peter Anvin wrote: On 09/10/2013 12:17 PM, David Lang wrote: In theory these blobs are traceable to a manufacturer. It's not really an indication that it's safe more than it's an indication that it hasn't been changed. But I haven't chased this very hard yet because of below... well, not if you are trying to defend against root breaking in to the machine. And we have at least some drivers where we even have the firmware in the Linux kernel tree, and thus aren't opaque blobs at all. I suspect we'll need, at some point, a way for vendors that aren't already doing signatures on their firmware in a device-specific way to do so in a kernel-supported way. The easiest (in terms of getting vendors to play along, not necessarily technically) might be a PGP signature (either inline or standalone) and have the public key as part of the driver? Why invent yet another method of verifying the integrity of a file based on a signature? Why not use the existing method for appraising files? Just create a new integrity hook at the appropriate place. Mimi -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] One more attempt at useful kernel lockdown
Some use cases require the ability to ensure that anything running in ring 0 is trusted code. We have support for signing the kernel and kernel modules, but there's still a range of exported kernel interfaces that make it easy to modify the running kernel. Previous attempts to implement a generic interface to restrict this have included a new capability (breaks existing userspace) and tying it to a requirement for signed modules (breaks assumptions in certain situations where userspace is already running with restricted privileges). So, this is my final attempt at providing the functionality I'm interested in without inherently tying it to Secure Boot. There's strong parallels between the functionality that I'm interested in and the BSD securelevel interface, so here's a trivial implementation. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said: So, this is my final attempt at providing the functionality I'm interested in without inherently tying it to Secure Boot. There's strong parallels between the functionality that I'm interested in and the BSD securelevel interface, so here's a trivial implementation. Although all the individual patches look like sane and reasonable things to do, I'm not at all convinced that sticking them all under control of one flag is really the right way to do it. In particular, there probably needs to be some re-thinking of the kexec, signed-module, and secure-boot stuff, as it's still a moving target. So, this is my final attempt at providing the functionality I'm interested in without inherently tying it to Secure Boot. You may as well bite the bullet on this one, and tie it together. Without Secure Boot, by the time your code runs it's already too late. That's the whole point of Secure Boot, after all. pgpe8NfrvaPO7.pgp Description: PGP signature
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 13:18 -0400, valdis.kletni...@vt.edu wrote: You may as well bite the bullet on this one, and tie it together. Without Secure Boot, by the time your code runs it's already too late. That's the whole point of Secure Boot, after all. It's already been made clear that nobody's interested in merging a solution that's specific to Secure Boot. I can add a command line option to set a default, and then anyone using an attesting bootloader (TPM/TXT) can verify the state. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, valdis.kletni...@vt.edu wrote: On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said: So, this is my final attempt at providing the functionality I'm interested in without inherently tying it to Secure Boot. There's strong parallels between the functionality that I'm interested in and the BSD securelevel interface, so here's a trivial implementation. Although all the individual patches look like sane and reasonable things to do, I'm not at all convinced that sticking them all under control of one flag is really the right way to do it. In particular, there probably needs to be some re-thinking of the kexec, signed-module, and secure-boot stuff, as it's still a moving target. Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. Or, eliminate the -1 permanently insecure option and make this a bitmask, if someone wants to enable every possible lockdown, have them set it to all 1's, define the bits only as you need them. right now 1 lock down modules 2 lock down kexec etc you may also want to have a 'disable module loading after this point' in the future. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. There's already a kernel option for that. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 11:53 -0700, David Lang wrote:
So is there a way to unify these different things rather than creating yet
another different knob?
We haven't found one that people consider generally acceptable.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:40 -0700, David Lang wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. There's already a kernel option for that. So, if there is an existing kernel option for this, why do we need a new one? There's an existing kernel option for I want to enforce module signatures but I don't care about anything else. There isn't for I want to prevent userspace from modifying my running kernel. So is there a way to unify these different things rather than creating yet another different knob? David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. Or, eliminate the -1 permanently insecure option and make this a bitmask, if someone wants to enable every possible lockdown, have them set it to all 1's, define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. pgpxQY_kaW9gQ.pgp Description: PGP signature
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. There's already a kernel option for that. So, if there is an existing kernel option for this, why do we need a new one? David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 11:40 -0700, David Lang wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. There's already a kernel option for that. So, if there is an existing kernel option for this, why do we need a new one? There's an existing kernel option for I want to enforce module signatures but I don't care about anything else. There isn't for I want to prevent userspace from modifying my running kernel. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Josh Boyer wrote: On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin h...@zytor.com wrote: On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote: On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. Or, eliminate the -1 permanently insecure option and make this a bitmask, if someone wants to enable every possible lockdown, have them set it to all 1's, define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. I.e. capabilities ;) Circles. All I see here are circles. the thing is that these are not circles. they are separate orthoginal things that you may or may not want to allow. If this was a simple set of circles, then this could be defined as a vector instead of bitmap, the further you go the more secure you are. But there are always going to be cases where you want to keep most of the lockdown, but relax just one specific aspect of it, so you want it to be a bitmap instead nested circles. Now, I know that some people are going to argue that if you relax one portion you have a hole in your secureity so it's not worth having any security at all. but I've been doing security for banks for the last 16 years and I can say that security is not a binary thing, just because there is one hole it isn't worthless to close another one. Attackers are not omnificent, they don't know everything there is to know about your system. If you block some holes you will make those attaches worthless. some holes you need to leave open to avoid breaking the business, and you either mitigate the risk in other ways (as discussed in this thread, by only loading modules from media that was tested to be intact, even if they aren't signed), or you accept that risk and factor the cost of cleanup into your cusiness plans. David Lang Having lived an entire release with a capabilities based mechanism for this in Fedora, please no. And if you are talking about non-POSIX capabilities as you mentioned earlier, that seems to be no different than having securelevel being a bitmask of, well, levels. I don't have much opinion on securelevel being a big hammer or a bitmask of finer grained things, but I do think it's a more manageable way forward. Calling the implementation capabilities seems to just be unnecessarily confusing. josh -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
I.e. capabilities ;) Circles. All I see here are circles. Having lived an entire release with a capabilities based mechanism for this in Fedora, please no. And if you are talking about non-POSIX capabilities as you mentioned earlier, that seems to be no different than having securelevel being a bitmask of, well, levels. I don't have much opinion on securelevel being a big hammer or a bitmask of finer grained things, but I do think it's a more manageable way forward. Calling the implementation capabilities seems to just be unnecessarily confusing. This is the term capability in the general sense, not the POSIX implementation thereof. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote: At least you should be able to unify the implementation, even if you don't unify the user visible knob Well sure, I could take this integer and merge another integer into it, but now you have the same value being modified by two different user-visible interfaces which aren't guaranteed to have the same semantics. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On 09/09/2013 12:58 PM, Josh Boyer wrote: This is the term capability in the general sense, not the POSIX implementation thereof. See the whole last paragraph. Particularly the last sentence. Yes. I disagree with not being able to use standard terminology. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:53 -0700, David Lang wrote: So is there a way to unify these different things rather than creating yet another different knob? We haven't found one that people consider generally acceptable. At least you should be able to unify the implementation, even if you don't unify the user visible knob If you do this with a capabilities approach, then you can implement the 'only load signed modules' bit and then have that bit call the existing kernel code, or change that existing kernel code to internally set the capabilities bit. I see you looking for two key things 1. a sledgehammer to say I want to be as secure as possible 2. no way to unset the setting (barring kernel bugs/vulnerabilities) implementing this as capabilities will still let you meet your goals, just have your tools that lock things down set the value to -1 (all 1's) As long as a bit cannot be unset, only set, it still satisfies your second requirement to not be able to back out. And for people who want a partial lockdown, the various capabilities bits allow them to get the amount of lockdown that they want. but if you are really trying to lock down a system, there are things that you want to do that will break normal users (things like disabling all module loading, disabling mounting of filesystems, disable the connection of new USB devices, etc) These are good tools to have available, but since using them will break some normal use cases, you really do want to be able to enable some things without enabling others. What you are seeing in this discussion is that even for the set of things that you consider 'essential' to lock down, other people see valid cases to not lock them down. If your tools only set 'known' or 'allocated' bits, you run the risk of not locking things down as tightly as you could, but if new bits are only allocated for new lockdown features, this is not a regression since you are no worse off than you would have been with an old kernel. Since we are not talking POSIX capabilities here, we are talking 'secure the system from even root' capabilities, there is no other system that we need to copy. The BSD securelevel approach is a simple big hammer approach, and it's easy to emulate with capabilities. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 13:15 -0700, David Lang wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote: At least you should be able to unify the implementation, even if you don't unify the user visible knob Well sure, I could take this integer and merge another integer into it, but now you have the same value being modified by two different user-visible interfaces which aren't guaranteed to have the same semantics. It's not that you merge integers, it's that the knob that currently sets the signed module only loading but not anything else would have it's implementation changed so that instead of doing whatever it currently does, it would instead make an internal call to set the require signed modules bit, and that one place would implement the lockdown. Thanks. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, Sep 9, 2013 at 4:10 PM, David Lang da...@lang.hm wrote: On Mon, 9 Sep 2013, Josh Boyer wrote: On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin h...@zytor.com wrote: On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote: On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. Or, eliminate the -1 permanently insecure option and make this a bitmask, if someone wants to enable every possible lockdown, have them set it to all 1's, define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. I.e. capabilities ;) Circles. All I see here are circles. the thing is that these are not circles. they are separate orthoginal things that you may or may not want to allow. If this was a simple set of circles, then this could be defined as a vector instead of bitmap, the further you go the more secure you are. I didn't mean your recommendation of using a bitmask. I understood your proposal and I don't even disagree with it really. I was replying to something else. josh -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote: At least you should be able to unify the implementation, even if you don't unify the user visible knob Well sure, I could take this integer and merge another integer into it, but now you have the same value being modified by two different user-visible interfaces which aren't guaranteed to have the same semantics. It's not that you merge integers, it's that the knob that currently sets the signed module only loading but not anything else would have it's implementation changed so that instead of doing whatever it currently does, it would instead make an internal call to set the require signed modules bit, and that one place would implement the lockdown. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote: On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: Given that we know that people want signed binaries without blocking kexec, you should have '1' just enforce module signing and '2' (or higher) implement a full lockdown including kexec. Or, eliminate the -1 permanently insecure option and make this a bitmask, if someone wants to enable every possible lockdown, have them set it to all 1's, define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. I.e. capabilities ;) -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 11:49 -0400, Matthew Garrett wrote: Some use cases require the ability to ensure that anything running in ring 0 is trusted code. We have support for signing the kernel and kernel modules, but there's still a range of exported kernel interfaces that make it easy to modify the running kernel. Previous attempts to implement a generic interface to restrict this have included a new capability (breaks existing userspace) and tying it to a requirement for signed modules (breaks assumptions in certain situations where userspace is already running with restricted privileges). So, this is my final attempt at providing the functionality I'm interested in without inherently tying it to Secure Boot. There's strong parallels between the functionality that I'm interested in and the BSD securelevel interface, so here's a trivial implementation. Thank you for not tying this functionality to UEFI secure boot. There are, and will continue to be, many systems out there that don't support UEFI secure boot, yet would be interested in this functionality. As David Lang aptly said, ... security is not a binary thing, just because there is one hole, it isn't worthless to close another one. Mimi -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: 1 lock down modules 2 lock down kexec Having thought about this, the answer is no. It presents exactly the same problem as capabilities do - the set can never be meaningfully extended. If an application sets only the bits it knows about, and if a new security-sensitive feature is added to the kernel, the feature will be left enabled and the system will be insecure. Alternatively, if an application sets all the bits regardless of whether it knows them or not, it may enable a lockdown feature that it otherwise required. The only way this is useful is if all the bits are semantically equivalent, and in that case there's no point in having anything other than a single bit. Users who want a more fine-grained interface should use one of the existing mechanisms for doing so - leave the kernel open and impose the security policy from userspace using either capabilities or selinux. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: 1 lock down modules 2 lock down kexec Having thought about this, the answer is no. It presents exactly the same problem as capabilities do - the set can never be meaningfully extended. If an application sets only the bits it knows about, and if a new security-sensitive feature is added to the kernel, the feature will be left enabled and the system will be insecure. Alternatively, if an application sets all the bits regardless of whether it knows them or not, it may enable a lockdown feature that it otherwise required. In this case you are no less secure than you were before the feature was added, you just can't take advantage of the new feature without updating userspace. That's a very common situation The only way this is useful is if all the bits are semantically equivalent, and in that case there's no point in having anything other than a single bit. Users who want a more fine-grained interface should use one of the existing mechanisms for doing so - leave the kernel open and impose the security policy from userspace using either capabilities or selinux. so if you only have a single bit, how do you deal with the case where that bit locks down something that's required? (your reason for not just setting all bits in the first approach) your arguments don't seem self consistent. why should there only be one way to lock down a system? there are lots of different use cases. If I'm building a kiosk PC (or voting machine), I want to disable a lot of things that I could not get away with disabling on a generic laptop. Are we going to have Securelevel, ReallySecurelevel, ReallyReallySecurelevel, etc? or can we accept that security is not binary and allow users to disable features in a more granualar way? And if SELinux can do the job, what is the reason for creating this new option? David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote: On Mon, Sep 9, 2013 at 4:19 PM, David Lang da...@lang.hm wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: 1 lock down modules 2 lock down kexec Having thought about this, the answer is no. It presents exactly the same problem as capabilities do - the set can never be meaningfully extended. If an application sets only the bits it knows about, and if a new security-sensitive feature is added to the kernel, the feature will be left enabled and the system will be insecure. Alternatively, if an application sets all the bits regardless of whether it knows them or not, it may enable a lockdown feature that it otherwise required. In this case you are no less secure than you were before the feature was added, you just can't take advantage of the new feature without updating userspace. That's a very common situation The only way this is useful is if all the bits are semantically equivalent, and in that case there's no point in having anything other than a single bit. Users who want a more fine-grained interface should use one of the existing mechanisms for doing so - leave the kernel open and impose the security policy from userspace using either capabilities or selinux. so if you only have a single bit, how do you deal with the case where that bit locks down something that's required? (your reason for not just setting all bits in the first approach) your arguments don't seem self consistent. why should there only be one way to lock down a system? there are lots of different use cases. If I'm building a kiosk PC (or voting machine), I want to disable a lot of things that I could not get away with disabling on a generic laptop. Are we going to have Securelevel, ReallySecurelevel, ReallyReallySecurelevel, etc? or can we accept that security is not binary and allow users to disable features in a more granualar way? And if SELinux can do the job, what is the reason for creating this new option? Not everyone uses SELinux. :) Also, it's rarely controlled the things we want to control here. It comes on by default (or its equivalent: AppArmour) in almost every shipping distro. The problem with Selinux/AppArmour isn't that they're not used by a lot of people, it's that they're hugely complex and the first time they deny access to something the user wants to do they get disabled (after the user grubbed around a bit to find out if he could fix whatever the problem was, concluded it was too difficult and turned them off). I have noticed that on every upgrade, AppArmour gets turned back on and I turn it off again when it causes some problem or other. However, as of OpenSUSE 12.3, I haven't actually turned it off yet (and I've been running with it for months) so perhaps the level of distro sophistication at configuring these things has finally reached the point where we can make them useful? James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, Sep 9, 2013 at 4:30 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote: On Mon, Sep 9, 2013 at 4:19 PM, David Lang da...@lang.hm wrote: And if SELinux can do the job, what is the reason for creating this new option? Not everyone uses SELinux. :) Also, it's rarely controlled the things we want to control here. It comes on by default (or its equivalent: AppArmour) in almost every shipping distro. Right, if LSM was meant here, yeah, I do use an LSM. But they, as a class of security policy in the kernel, handle isolation of entirely different things. The goal of no way to mess with ring-0 isn't really related to the goals of the LSM in general, or specific MACs in particular. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 16:19 -0700, David Lang wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: Having thought about this, the answer is no. It presents exactly the same problem as capabilities do - the set can never be meaningfully extended. If an application sets only the bits it knows about, and if a new security-sensitive feature is added to the kernel, the feature will be left enabled and the system will be insecure. Alternatively, if an application sets all the bits regardless of whether it knows them or not, it may enable a lockdown feature that it otherwise required. In this case you are no less secure than you were before the feature was added, you just can't take advantage of the new feature without updating userspace. No. Say someone adds an additional lockdown bit to forbid raw access to mounted block devices. The Turn everything off approach now means that I won't be able to perform raw access to mounted block devices, even if that's something that my use case relies on. The only way this is useful is if all the bits are semantically equivalent, and in that case there's no point in having anything other than a single bit. Users who want a more fine-grained interface should use one of the existing mechanisms for doing so - leave the kernel open and impose the security policy from userspace using either capabilities or selinux. so if you only have a single bit, how do you deal with the case where that bit locks down something that's required? (your reason for not just setting all bits in the first approach) Because that bit is well-defined, and if anything is added to it that doesn't match that definition then it's a bug. your arguments don't seem self consistent. You don't seem to have been paying attention to the past 12 months of discussion. If I'm building a kiosk PC (or voting machine), I want to disable a lot of things that I could not get away with disabling on a generic laptop. Are we going to have Securelevel, ReallySecurelevel, ReallyReallySecurelevel, etc? or can we accept that security is not binary and allow users to disable features in a more granualar way? Anything more granular means that you trust your userspace, and if you trust your userspace then you can already set up a granular policy using the existing tools for that job. So just use the existing tools. And if SELinux can do the job, what is the reason for creating this new option? Because you can't embed an unmodifiable selinux policy in the kernel. -- Matthew Garrett matthew.garr...@nebula.com
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, 10 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote: On Tue, 10 Sep 2013, Matthew Garrett wrote: No. Say someone adds an additional lockdown bit to forbid raw access to mounted block devices. The Turn everything off approach now means that I won't be able to perform raw access to mounted block devices, even if that's something that my use case relies on. I was meaning that if you only turn off features that you know about, the addition of a new thing that can be disabled doesn't make you any worse off than you were. Someone adds a new install_evil() syscall and adds a disable bit. If I don't disable it, I'm now vulnerable. Please pay attention to earlier discussion. so instead they add install_evil() and don't have it be disabled by your big switch. or do you think the existance of this switch will give you veto power over any new system calls unless they include the ability for them to be disabled if they don't match your security model. so if you only have a single bit, how do you deal with the case where that bit locks down something that's required? (your reason for not just setting all bits in the first approach) Because that bit is well-defined, and if anything is added to it that doesn't match that definition then it's a bug. it may be well defined, but that doesn't mean that it actually matches what the system owner wants to do. If it doesn't match what the system owner wants to do, the system owner doesn't set it. The system owner uses a more appropriate security mechanism instead. SELinux is a wonderful example of how making a system that users cannot change doesn't improve security, it just gets disabled instead. The idea that the programmer can possibly anticipate all possible needs and provide a switch for exactly that need is just wrong. Users will have needs that you never thought of. The best systems are the ones where the creators look at what users are doing and react with I never imagined doing that Describe the security case for disabling PCI BAR access but permitting i/o port access. Simple, I have some device that lives on those I/O ports that I want to be able to use. Anything more granular means that you trust your userspace, and if you trust your userspace then you can already set up a granular policy using the existing tools for that job. So just use the existing tools. If you can't trust your userspace, how do you know that the userspace has set the big hammer flag in the first place? if you can trust it to throw that switch, you can trust it to throw multiple smaller switches. Hence the final patch in the series, and hence also the suggestion for exposing it as a command line option that can be set by the bootloader during an attested boot. And if SELinux can do the job, what is the reason for creating this new option? Because you can't embed an unmodifiable selinux policy in the kernel. Why not, have the policy set in an initramfs that's part of the kernel and have part of that policy be to block all access to the selinux controls. Because then someone disables selinux on the kernel command line. If they can modify the command line, they can remove your command line switch to turn this on. If you really care about this, why are you using a bootloader that lets you modify the kernel command line in the first place? In any case, even if you make it impossible to change from the command line, you won't prevent people from changing your system (unless you take control completely away from them with TPM or similar) remember that the system integrity checking of the original Tivo was defeated by someone dong a binary patch to bypass a routine that they didn't understand that took a lot of time, so they did a binary patch to the bios to speed up boot and discovered that what they did was disable the system integrity checking. users who own the systems are going to modify them and bypass any restrictions you want to impose. users who don't own the systems can be defeated by simply not offering them the option to change the settings in the first place. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 2013-09-09 at 20:09 -0700, David Lang wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
Someone adds a new install_evil() syscall and adds a disable bit. If I
don't disable it, I'm now vulnerable. Please pay attention to earlier
discussion.
so instead they add install_evil() and don't have it be disabled by your big
switch.
And that's a bug, so we fix it.
Describe the security case for disabling PCI BAR access but permitting
i/o port access.
Simple, I have some device that lives on those I/O ports that I want to be
able
to use.
That's a great argument for permitting i/o port access. But in that
case, why are you disabling BAR access? You can use the i/o port access
to reprogram the device in question into a range you can modify, which
allows you to avoid the BAR restriction.
Because then someone disables selinux on the kernel command line.
If they can modify the command line, they can remove your command line switch
to
turn this on.
Not in the secure boot case.
If you really care about this, why are you using a bootloader that lets you
modify the kernel command line in the first place?
And then the user just modifies the configuration file instead.
In any case, even if you make it impossible to change from the command line,
you
won't prevent people from changing your system (unless you take control
completely away from them with TPM or similar)
That's fine. People are free to modify their own systems.
remember that the system integrity checking of the original Tivo was defeated
by
someone dong a binary patch to bypass a routine that they didn't understand
that
took a lot of time, so they did a binary patch to the bios to speed up boot
and
discovered that what they did was disable the system integrity checking.
That's why modern systems require signed firmware updates.
users who own the systems are going to modify them and bypass any
restrictions
you want to impose.
The idea isn't to produce something that's impossible for the owner of a
system to disable. The idea is to produce something that can't be used
to circumvent the security policy that the system owner has chosen.
Could you please give me the benefit of the doubt and assume that I'm
not completely unaware of how computers work?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
