Re: GRUB trusted boot framework
On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote: > > If we could agree on this, then I think we could find a way to extend the GRUB > module system to fully allow this. > > From my point of view the minimal needed features for these systems are: > - easy exchange of the MBR binary to be installed > - easy exchange of the core.img loader binary > - hooks for any disk read (not sure if write is necessary) > > (I didn't check if any of these is already implemented) > > Last part to agree on would then be, that these infrastructure features should > be in the mainline code. Hi, The last stage is much simpler. Just put /boot/ in a crypted filesystem (we have a patch liing around which is pending to merge). That only leaves MBR and core.img. You can either check both from firmware (does any BIOS allow this?) or do some funny gimmicks in MBR ;-) > That way it would be easy to develop various trusted boot solutions (and > probably some other systems too), but keep all the controversial code out of > mainline. I appreciate your interest in avoiding controversy. If you want that, then please don't refer to this as "trusted". It is implied that all the code in GRUB is already trusted by its user. The difference here is that our system would be hardened against physical attack, it doesn't change anything about who is able to "trust" your computer and who isn't. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
phcoder wrote: > Jan Alsenz wrote: >> phcoder wrote: Oh, I want! If I remember correctly, exactly this broke the protection on some game console! >>> Do you refer to Xbox crack based on King kong game? For once their goal >>> is the evil one. For second the problem is a buffer overflow in >>> rendering engine, not the not checking part. If you want to make a >>> secure system it must be free of such bugs. Or you may as well hash the >>> whole hd and be hacked through network code. Here is where advantages of >>> open developement come in play >> >> It is totally irrelevant, if the purpose is good or evil, if it can >> break the >> system. >> And since it is awfully difficult to produce bug free code, the goal >> must be to >> reduce the code that has to be bug free to the absolute (and openly >> known) >> minimum: In this case I'd say the reasonable choice is the fs driver >> code. >> > You can't really do this. You can safeguard from e.g. fonts drivers > bugs. But what do you do with vulnerabilities with usb code. Some may > connect an evil mouse to the computer Ok, your right, the definition should be: The fs drivers, and everything else, that takes non disk input (this includes keyboard, command-line parser, mouse, network, pci probe, etc.). But I still think, that this is better, that everything above plus any component, that reads a file! If there is a way to prevent bugs in a part of our code, to hit our security system, we should use it, because as we know - bugs DO occur. There is alway the chance to be hit by new ideas and attack vectors, you can't prevent that, but if we can, we should protect against the one we know. But how do I get it into every possible loader? >>> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, >>> GZIO_TRANSPARENT) >>> s/grub_file_open(filename)/grub_gnupg_open(filename, 0) >> >> With "every possible loader", I wanted to include unknown future loaders. >> > New loaders will use the existing ones as a template. I did > >> That would be a good idea. >> The difference between your and my solution was, that mine it had >> secure as default. > Mine too. It involves just using right code. If a developer wants to > wrote unsecure code he can always, otherwise I don't see why he wouldn't Yes, but it's a matter good design and convenience. If it can, secure should always be default, without anyone having to think about it. If security needs to be explicitly put in a and someone fails to do that, he can blame you for not telling him to do that, but if you have secure defaults and someone uses insecure, you can blame him for not following good practices/reading the docs/etc. This is especially useful if many people work on the code, like open source projects, and not everyone might be aware of the security implication of his/her actions. > use e.g. linux loader as a template >> - (It may be useful to have some order within the hooks) > It's even necessary. Otherwise you can't know if you have first to > compress or to sign Agreed. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Jan Alsenz wrote: phcoder wrote: Oh, I want! If I remember correctly, exactly this broke the protection on some game console! Do you refer to Xbox crack based on King kong game? For once their goal is the evil one. For second the problem is a buffer overflow in rendering engine, not the not checking part. If you want to make a secure system it must be free of such bugs. Or you may as well hash the whole hd and be hacked through network code. Here is where advantages of open developement come in play It is totally irrelevant, if the purpose is good or evil, if it can break the system. And since it is awfully difficult to produce bug free code, the goal must be to reduce the code that has to be bug free to the absolute (and openly known) minimum: In this case I'd say the reasonable choice is the fs driver code. You can't really do this. You can safeguard from e.g. fonts drivers bugs. But what do you do with vulnerabilities with usb code. Some may connect an evil mouse to the computer But how do I get it into every possible loader? s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT) s/grub_file_open(filename)/grub_gnupg_open(filename, 0) With "every possible loader", I wanted to include unknown future loaders. New loaders will use the existing ones as a template. I did That would be a good idea. The difference between your and my solution was, that mine it had secure as default. Mine too. It involves just using right code. If a developer wants to wrote unsecure code he can always, otherwise I don't see why he wouldn't use e.g. linux loader as a template - (It may be useful to have some order within the hooks) It's even necessary. Otherwise you can't know if you have first to compress or to sign ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
phcoder wrote: >> Oh, I want! >> If I remember correctly, exactly this broke the protection on some >> game console! > Do you refer to Xbox crack based on King kong game? For once their goal > is the evil one. For second the problem is a buffer overflow in > rendering engine, not the not checking part. If you want to make a > secure system it must be free of such bugs. Or you may as well hash the > whole hd and be hacked through network code. Here is where advantages of > open developement come in play It is totally irrelevant, if the purpose is good or evil, if it can break the system. And since it is awfully difficult to produce bug free code, the goal must be to reduce the code that has to be bug free to the absolute (and openly known) minimum: In this case I'd say the reasonable choice is the fs driver code. >> But how do I get it into every possible loader? > s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT) > s/grub_file_open(filename)/grub_gnupg_open(filename, 0) With "every possible loader", I wanted to include unknown future loaders. >> I also checked the loopback code and it uses the standard >> grub_file_read, so for >> these cases a read version without a hook would be needed. > > Then how is your proposition with two file read functions different from > mine with two file read functions? What can be proposed is to merge > somehow all opening functions into one with following protype > grub_file_open (const char *filename, int flags, struct grub_file_info > *info) > Then on opening the function will do the default behavior with possible > override possible through flags. It has an advantage of future > expandability for possible new transparent transformations That would be a good idea. The difference between your and my solution was, that mine it had secure as default. I'm not yet sure about the flag solution though. If we want to keep the solution general - which I would prefer - the flag is only known to the transformation and the code who wants to avoid it. To clarify: I'm thinking about a general hook/transformation solution in kern/file.c . Everyone can register a hook there, and now the goal of the flags is, to selectively enable or disable hooks. Problem is, that these hooks are not necessarily all known to all components. My first thought for a solution was something like: - Every hook gets an unique ID (distribution controlled e.g. via wiki) - The flags are lists of these IDs - A hook can by default be active or inactive - (It may be useful to have some order within the hooks) Apart from solving the problem, this solution would have a few other advantages: - Existing filters, like gzio, could be ported to this generic framework - IDs could be grouped into classes, e.g. to say "I don't want any security hooks on this operation" for the loopback device I'm not yet happy with the flag-list implementation, so if someone has a better idea, I would be happy to hear it. >> By the way we're assuming here, that every file-system driver is free of >> exploitable bugs! >> To avoid this a real disk read hook would be needed, but of course >> that is >> largely impractical. (There might be options with "sparce" hashing - >> meaning >> only hashing the parts that are actually read, and including the map >> of read >> areas into the final hash) > And then after a minor write or fs self-maintenance it suddenly stops > working. You may as well not boot at all. Perfectly secure booter in 2 > bytes of x86-assembly: > eb fe : self: jmp self That's also part of what I meant with "largely impractical" ;) Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Oh, I want! If I remember correctly, exactly this broke the protection on some game console! Do you refer to Xbox crack based on King kong game? For once their goal is the evil one. For second the problem is a buffer overflow in rendering engine, not the not checking part. If you want to make a secure system it must be free of such bugs. Or you may as well hash the whole hd and be hacked through network code. Here is where advantages of open developement come in play But how do I get it into every possible loader? s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT) s/grub_file_open(filename)/grub_gnupg_open(filename, 0) I also checked the loopback code and it uses the standard grub_file_read, so for these cases a read version without a hook would be needed. Then how is your proposition with two file read functions different from mine with two file read functions? What can be proposed is to merge somehow all opening functions into one with following protype grub_file_open (const char *filename, int flags, struct grub_file_info *info) Then on opening the function will do the default behavior with possible override possible through flags. It has an advantage of future expandability for possible new transparent transformations By the way we're assuming here, that every file-system driver is free of exploitable bugs! To avoid this a real disk read hook would be needed, but of course that is largely impractical. (There might be options with "sparce" hashing - meaning only hashing the parts that are actually read, and including the map of read areas into the final hash) And then after a minor write or fs self-maintenance it suddenly stops working. You may as well not boot at all. Perfectly secure booter in 2 bytes of x86-assembly: eb fe : self: jmp self Greets, Jan Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Vesa Jääskeläinen wrote: > Jan Alsenz wrote: >> Vesa Jääskeläinen write: >>> I do like the idea what some protected systems use, they sign the binary >>> (in our case .mod file and kernels of loaded OSes). Now in that scenario >>> it is responsibility of the kernel module loader to first verify the >>> signature for correctness. This way the signature checking would be >>> somewhat transparent to the rest of the system. >>> >>> I do not see a need to add any hooks to disk read. It should be >>> responsibility of the code needing signature checking to handle that. >> Well, since to trusted operation should be transparent (and in my opinion >> should >> not need code changes in something like the loaders - so if someone writes a >> new >> loader, it should work by default), that's where the hooks come in. >> Maybe the "disk read" was misleading, what I meant where "file reads". > > Hi, > > Well.. you probably don't want to verify authenticity of the fonts or > bitmaps in graphical menu? Oh, I want! If I remember correctly, exactly this broke the protection on some game console! > Anyway. I think the right place for verification hook in this case is > the module or OS kernel loader. > > If you think otherwise. Then you have to provide a complete technical > design how it should work as I see no other good choice for it. > > (actually there is one other place that could be used, but I let you > come up with the idea after you have given a bit more though on the > implementation side :)) But how do I get it into every possible loader? My current suggestion would be to put a hook possibility into kern/file.c and extend the fs interface with a function to compare to files, to get rid of the double hashing problem mentioned by phcoder. I also checked the loopback code and it uses the standard grub_file_read, so for these cases a read version without a hook would be needed. By the way we're assuming here, that every file-system driver is free of exploitable bugs! To avoid this a real disk read hook would be needed, but of course that is largely impractical. (There might be options with "sparce" hashing - meaning only hashing the parts that are actually read, and including the map of read areas into the final hash) Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Jan Alsenz wrote: > Vesa Jääskeläinen write: >> I do like the idea what some protected systems use, they sign the binary >> (in our case .mod file and kernels of loaded OSes). Now in that scenario >> it is responsibility of the kernel module loader to first verify the >> signature for correctness. This way the signature checking would be >> somewhat transparent to the rest of the system. >> >> I do not see a need to add any hooks to disk read. It should be >> responsibility of the code needing signature checking to handle that. > > Well, since to trusted operation should be transparent (and in my opinion > should > not need code changes in something like the loaders - so if someone writes a > new > loader, it should work by default), that's where the hooks come in. > Maybe the "disk read" was misleading, what I meant where "file reads". Hi, Well.. you probably don't want to verify authenticity of the fonts or bitmaps in graphical menu? Anyway. I think the right place for verification hook in this case is the module or OS kernel loader. If you think otherwise. Then you have to provide a complete technical design how it should work as I see no other good choice for it. (actually there is one other place that could be used, but I let you come up with the idea after you have given a bit more though on the implementation side :)) Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Vesa Jääskeläinen write: > Hi All, > > Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it > to the topic first... (I am already waiting for summary of that other > discussion at some point ;)) > > Jan Alsenz wrote: >> Next I think we can agree, that some sort of trusted boot chain can be >> useful. >> >> Also there should be more than one implementation for this (or at least the >> possibility to have them). > > I like the idea of modularity in here. However. It should work with > different schemes but same generic interfaces if that is what is planned. That was what I had in mind. >> If we could agree on this, then I think we could find a way to extend the >> GRUB >> module system to fully allow this. >> >> From my point of view the minimal needed features for these systems are: >> - easy exchange of the MBR binary to be installed >> - easy exchange of the core.img loader binary >> - hooks for any disk read (not sure if write is necessary) > > Note: I will skip MBR+core.img validation for a reason here now. > > I do like the idea what some protected systems use, they sign the binary > (in our case .mod file and kernels of loaded OSes). Now in that scenario > it is responsibility of the kernel module loader to first verify the > signature for correctness. This way the signature checking would be > somewhat transparent to the rest of the system. > > I do not see a need to add any hooks to disk read. It should be > responsibility of the code needing signature checking to handle that. Well, since to trusted operation should be transparent (and in my opinion should not need code changes in something like the loaders - so if someone writes a new loader, it should work by default), that's where the hooks come in. Maybe the "disk read" was misleading, what I meant where "file reads". Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Do you know if it is possible to determine where the files come from? Well it's possible looking at filename and root drive but it's not reliable (e.g. ata0 can be hd0 but also hd1, when we'll have network support it will be even less obvious. Actually it's something grub2's architecture is trying to hide) and in this context not relevant. If signature is correct does it matter where the file comes from? At most what is necessary for these functions is being able to read the files like .sig but it's trivial when filename is given Hmm, to be precise we're interested in file reads. So if the loopback image is implemented as disk driver, it should work. AFAIR it's a disk driver which reads from file. IMO disk read hooks will result in messy and bug-prone design which is incompatible with grub2's versatility. And only the files that end up in memory or control grub need to be checked. Greets, Jan Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
phcoder wrote: >> Ok, but your already talking of a specific solution here. My >> conclusion would >> be: The hooks need to be able to determine the filename, that is >> currently read. >> > And then also where it comes from but some files may have different > filenames. IMO the solution work independently of the order of files and > where they come from. TPM checking is too limited for grub2 architecture. I agree and I'm not talking TPM here. Do you know if it is possible to determine where the files come from? >> The reason why I want generic read hooks, is that I want it to inter >> operate >> with everything else. So I should not need to figure out what files >> e.g. the >> linux loader is going to read, or change it's code to do so. > You can do anything secure without collaboration from upper layers. > Consider a huge loopback image from which you load only kernel. In you > solution it will unnecessary check the whole image Hmm, to be precise we're interested in file reads. So if the loopback image is implemented as disk driver, it should work. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Hi All, Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it to the topic first... (I am already waiting for summary of that other discussion at some point ;)) Jan Alsenz wrote: > Next I think we can agree, that some sort of trusted boot chain can be useful. > > Also there should be more than one implementation for this (or at least the > possibility to have them). I like the idea of modularity in here. However. It should work with different schemes but same generic interfaces if that is what is planned. > If we could agree on this, then I think we could find a way to extend the GRUB > module system to fully allow this. > > From my point of view the minimal needed features for these systems are: > - easy exchange of the MBR binary to be installed > - easy exchange of the core.img loader binary > - hooks for any disk read (not sure if write is necessary) Note: I will skip MBR+core.img validation for a reason here now. I do like the idea what some protected systems use, they sign the binary (in our case .mod file and kernels of loaded OSes). Now in that scenario it is responsibility of the kernel module loader to first verify the signature for correctness. This way the signature checking would be somewhat transparent to the rest of the system. I do not see a need to add any hooks to disk read. It should be responsibility of the code needing signature checking to handle that. And please try to share some code with password/authentication features :) > Last part to agree on would then be, that these infrastructure features should > be in the mainline code. > That way it would be easy to develop various trusted boot solutions (and > probably some other systems too), but keep all the controversial code out of > mainline. Yes. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
Ok, but your already talking of a specific solution here. My conclusion would be: The hooks need to be able to determine the filename, that is currently read. And then also where it comes from but some files may have different filenames. IMO the solution work independently of the order of files and where they come from. TPM checking is too limited for grub2 architecture. The reason why I want generic read hooks, is that I want it to inter operate with everything else. So I should not need to figure out what files e.g. the linux loader is going to read, or change it's code to do so. You can do anything secure without collaboration from upper layers. Consider a huge loopback image from which you load only kernel. In you solution it will unnecessary check the whole image Greets, Jan Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
phcoder wrote: >> - hooks for any disk read (not sure if write is necessary) > This way how trusted grub does it is an ad-hoc solution which results in > a MESS. They just try to hash and rehash everything without design. So > if grub is instructed to load all modules in a directory and filesystem > is reindexed then grub will load the same modules in a different order > which results in a different hash. IMO we can't allow such thing to come > to grub2 it's just against its basic design principles. Much better > would be a layer similar to gzio: > > grub_gnupg_open (const char *filename, int flags, struct grub_gnupg_info > *info); > Which internally checks the certificate. This layer can also > encrypt/decrypt from gnupg containers > Then all kernel and config loads would use this function instead of > grub_gzio_open and grub_gnupg_open would check if its contents is > gzipped. Flags can include: > GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED > if signature can be checked later on (e.g. signed ELF) > Then the behavior is controlled by an environment variable > allow_unsigned=yes|no > If grub_gnupg_open is invoked without GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED > and allow_unsigned=no and signature is broken or not present it should > prompt for password (if it isn't supplied yet) and write something like > File %s is unsigned. Are you sure you want to load it? Type "YES" if you > do. Ok, but your already talking of a specific solution here. My conclusion would be: The hooks need to be able to determine the filename, that is currently read. The reason why I want generic read hooks, is that I want it to inter operate with everything else. So I should not need to figure out what files e.g. the linux loader is going to read, or change it's code to do so. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB trusted boot framework
- hooks for any disk read (not sure if write is necessary) This way how trusted grub does it is an ad-hoc solution which results in a MESS. They just try to hash and rehash everything without design. So if grub is instructed to load all modules in a directory and filesystem is reindexed then grub will load the same modules in a different order which results in a different hash. IMO we can't allow such thing to come to grub2 it's just against its basic design principles. Much better would be a layer similar to gzio: grub_gnupg_open (const char *filename, int flags, struct grub_gnupg_info *info); Which internally checks the certificate. This layer can also encrypt/decrypt from gnupg containers Then all kernel and config loads would use this function instead of grub_gzio_open and grub_gnupg_open would check if its contents is gzipped. Flags can include: GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED if signature can be checked later on (e.g. signed ELF) Then the behavior is controlled by an environment variable allow_unsigned=yes|no If grub_gnupg_open is invoked without GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED and allow_unsigned=no and signature is broken or not present it should prompt for password (if it isn't supplied yet) and write something like File %s is unsigned. Are you sure you want to load it? Type "YES" if you do. Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB trusted boot framework
Hello! Alright, lets try to end the pointless (in the sense, that I guess noone here, including myself, will change their opinion anytime soon) TPM discussion and get something done. First I'd say we can agree, that we don't agree on whether/how to use a TPM. I don't know about you, but I can perfectly live with that! Next I think we can agree, that some sort of trusted boot chain can be useful. Also there should be more than one implementation for this (or at least the possibility to have them). If we could agree on this, then I think we could find a way to extend the GRUB module system to fully allow this. From my point of view the minimal needed features for these systems are: - easy exchange of the MBR binary to be installed - easy exchange of the core.img loader binary - hooks for any disk read (not sure if write is necessary) (I didn't check if any of these is already implemented) Last part to agree on would then be, that these infrastructure features should be in the mainline code. That way it would be easy to develop various trusted boot solutions (and probably some other systems too), but keep all the controversial code out of mainline. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
