Re: Ubuntu 16.04 Secure Boot Policy
On Thu, 14 Jul 2016 17:44:22 +0200 Xen wrote: > Dale Amon schreef op 14-07-2016 16:55: > > I don't particularly like Secure Boot and UEFI, and in fact for > > development work I prefer having the ability to turn them off. > > > > That said, I would almost certainly want to set it up for a > > spacecraft system. There are reasons for Secure Boot if you > > are security conscious. It is a way to stop the bad guys'n'gals > > or at least make life very difficult for them. > > > > To every season, there is a purpose. > > But the beauty is in recognising when that season is, and when not. > > When it's the time for laughter, you shouldn't be crying, and vice > versa. At least, usually not ;-). > > Most of life comes down to misrecognising the seasons. At least, the > life we see around us. The society we live in. > > Not only do most people think half of life does /not/ have a season, the > things they believe /do/ have a season, are mostly to them, always. > > I believe in this case, Secure Boot is one of those things. If I wanted > to find a reason to use it > > It would be when people had physical access to my computer and I would > want to protect it also using a BIOS password. This would be a scenario > in which such access could be prevalent and common. > > Since it doesn't actually protect your data (someone could take out your > harddrive) it is merely meant to prevent anyone else from using the > computer whatsoever. > > That is the reality I would envision for it. If you consider not being > tampered with the kernel or its modules to be a reason, which I guess is > what it has been "intended" for then you must reasonably assume that > most common hacks couldn't be done on a running system and would require > a reboot. I mean a breach of whatever. Tampering with a system is a long > term process. For instance, on most of my machines, triggering a reboot > would case the encryption prompt to prevent the system from booting. > Linux to my recollection never really spontaneously reboot. That in > itself would be a weird sign of something. > > If I am a hacker and I want to do "harm" I want to be as invisible as > possible. The longer they don't see me, the less worries I have. I > cannot expect to be able to reboot someone's machine. At the same time, > I cannot expect automated scripts to really deal with that sort of > thing. > > Now "secure boot" is a bit of a misnomer because the real protection is > against the loading of kernel modules in a running system, I would say. > > However security comes at a price. In any automated secure-boot system, > the keys will be at default locations. If you do not store your keys > offline, what good will your system have? And if you do store them > offline, how are you going to deal with the hassle of upgrades and > changes? You won't. > > Therefore the only meaningful place a secure boot system would have, is > in a system that is really locked down, and also does not experience any > sense of upgrades. > > In all other cases I, as a user, would be hindered in doing my thing. To > give a small example of how idiotic it can get. > > Systemd cryptsetup does not support keyscripts. To get keyscript support > for tertiary or secondary mounts (crypts) you have to disable the > systemd feature and reenable sysv. However that is rather hard for a > beginner in systemd mechanics. So what you end up with is that nofail > doesn't work in fstab, and if your mount fails, or your encrypt fails, > then your entire system fails to boot. > > Now suppose you have taken some time to store your key elsewhere, or to > derive it from a secondary source. Such derivation could depend on your > local system parameters as well as network parameters. Now if those > parameters change, your system fails to boot. > > Now in order to boot we must do a thing like init=/bin/bash, because the > thing doesn't timeout either. But after init=/bin/bash, we won't have > LVM, somehow it fails to load (except for the first volume, on which > root is located). So now we first have to go into fstab and disable the > mount for the crypt, then reboot, then regenerate the key based on the > new parameters, install it into the crypt, reenable the mount, and > reboot once more. > > However LUKS does not allow you to remove keys without being in > possession of them. > > How are you going to remove the old key that was generated based on the > old parameters, that you no longer have? Trust me, you will forget to > change the key in the container prior to making the changes. > > You now have to keep the key around. Where are you going to keep the key > around? The whole idea in the beginning was to not keep the key around. > > Now your key is just sitting in /root for convenience sake. The whole > system is almost entirely defeated, based on 3 reasons: > > - systemd fails booting or doesn't provide adequate support for > something th
Re: Ubuntu 16.04 Secure Boot Policy
Dale Amon schreef op 14-07-2016 16:55: I don't particularly like Secure Boot and UEFI, and in fact for development work I prefer having the ability to turn them off. That said, I would almost certainly want to set it up for a spacecraft system. There are reasons for Secure Boot if you are security conscious. It is a way to stop the bad guys'n'gals or at least make life very difficult for them. To every season, there is a purpose. But the beauty is in recognising when that season is, and when not. When it's the time for laughter, you shouldn't be crying, and vice versa. At least, usually not ;-). Most of life comes down to misrecognising the seasons. At least, the life we see around us. The society we live in. Not only do most people think half of life does /not/ have a season, the things they believe /do/ have a season, are mostly to them, always. I believe in this case, Secure Boot is one of those things. If I wanted to find a reason to use it It would be when people had physical access to my computer and I would want to protect it also using a BIOS password. This would be a scenario in which such access could be prevalent and common. Since it doesn't actually protect your data (someone could take out your harddrive) it is merely meant to prevent anyone else from using the computer whatsoever. That is the reality I would envision for it. If you consider not being tampered with the kernel or its modules to be a reason, which I guess is what it has been "intended" for then you must reasonably assume that most common hacks couldn't be done on a running system and would require a reboot. I mean a breach of whatever. Tampering with a system is a long term process. For instance, on most of my machines, triggering a reboot would case the encryption prompt to prevent the system from booting. Linux to my recollection never really spontaneously reboot. That in itself would be a weird sign of something. If I am a hacker and I want to do "harm" I want to be as invisible as possible. The longer they don't see me, the less worries I have. I cannot expect to be able to reboot someone's machine. At the same time, I cannot expect automated scripts to really deal with that sort of thing. Now "secure boot" is a bit of a misnomer because the real protection is against the loading of kernel modules in a running system, I would say. However security comes at a price. In any automated secure-boot system, the keys will be at default locations. If you do not store your keys offline, what good will your system have? And if you do store them offline, how are you going to deal with the hassle of upgrades and changes? You won't. Therefore the only meaningful place a secure boot system would have, is in a system that is really locked down, and also does not experience any sense of upgrades. In all other cases I, as a user, would be hindered in doing my thing. To give a small example of how idiotic it can get. Systemd cryptsetup does not support keyscripts. To get keyscript support for tertiary or secondary mounts (crypts) you have to disable the systemd feature and reenable sysv. However that is rather hard for a beginner in systemd mechanics. So what you end up with is that nofail doesn't work in fstab, and if your mount fails, or your encrypt fails, then your entire system fails to boot. Now suppose you have taken some time to store your key elsewhere, or to derive it from a secondary source. Such derivation could depend on your local system parameters as well as network parameters. Now if those parameters change, your system fails to boot. Now in order to boot we must do a thing like init=/bin/bash, because the thing doesn't timeout either. But after init=/bin/bash, we won't have LVM, somehow it fails to load (except for the first volume, on which root is located). So now we first have to go into fstab and disable the mount for the crypt, then reboot, then regenerate the key based on the new parameters, install it into the crypt, reenable the mount, and reboot once more. However LUKS does not allow you to remove keys without being in possession of them. How are you going to remove the old key that was generated based on the old parameters, that you no longer have? Trust me, you will forget to change the key in the container prior to making the changes. You now have to keep the key around. Where are you going to keep the key around? The whole idea in the beginning was to not keep the key around. Now your key is just sitting in /root for convenience sake. The whole system is almost entirely defeated, based on 3 reasons: - systemd fails booting or doesn't provide adequate support for something that used to be common - luks requires a key to be given before being removed, even when there is really no such technical requirement. - it is human nature to only realize a change after it has happened. Something that is in essence rather ea
Re: Ubuntu 16.04 Secure Boot Policy
I don't particularly like Secure Boot and UEFI, and in fact for development work I prefer having the ability to turn them off. That said, I would almost certainly want to set it up for a spacecraft system. There are reasons for Secure Boot if you are security conscious. It is a way to stop the bad guys'n'gals or at least make life very difficult for them. To every season, there is a purpose. -- +---+ | Dale Amon Immortal Data a...@vnl.com| | CEO Data Systems for Deep Space and Time| +---+ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
