Ubuntu 16.04 Secure Boot Policy

[Brendan Perrine]

On Thu, 14 Jul 2016 17:44:22 +0200
Xen <list at xenhideout.nl> 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 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 easy, is now the most complicated, 
> idiocy-trodden and riddel-riddled thing there can be. And what looked 
> like a good idea (and still is) is just defeated by software mechanics 
> and human nature.
> 
> A solution is only as good as the willingness of people to use it.
> 
> We are bargaining in sayings here ;-).
> 
> Personally if I was designing such space systems I would be focussing on 
> providing outer layers of security so that inner layers can be more 
> flexible. If you have room to move around inside your little hub, that 
> makes life so much more pleasant. You can leave defenses to the outer 
> layers (of which ouf course there could be several).
> 
> Securing "boot" is the most inner layer there is, almost, apart from 
> directly patching the running kernel, which is almost the same.
> 
> And I would say it gives a false sense of security because most attacks 
> do not need such measures; you would only need it to completely take 
> over a system and hope to remain undetected for the longest time, for 
> instance.
> 
> And while you focus on the hidden sanctum, people might be roving about 
> on the outskirts without you noticing it. Because you think you're safe 
> and hence you are not paying much attention anymore.
> 
> Here is a guy who depended on the safety of some autonomous system that 
> would do his work for him:
> 
> http://www.marketwatch.com/story/driver-in-fatal-tesla-crash-previously-had-posted-video-of-autopilot-saving-him-2016-06-30
> 
> If you think you can depend on automatic systems, you will definitely 
> pay less attention.
> 
> After all, why would you or should you? Most of the time it won't be 
> necessary. And in those times that it is necessary, you will be too slow 
> to react. Your sense have already been dulled.
> 
> So I guess that to everything is a season.
> 
> It's just that the customer is usually not asked about this.
> 
> Or they are misinformed. It is fine to think your season is now, but 
> most of the time the voice of the people it is actually about, is kinda 
> getting disregarded. The ones who actually have to use it are not the 
> ones who are promoting it.
> 
> Put differently, the ones who promote it, are usually not the ones who 
> have to suffer the consequences as a regular user (because they are not 
> regular users).
> 
> It is real cool and sweet to promote something when you know the ins and 
> outs of something and you can deal with the consquences the moment 
> something goes wrong. It is not cool and sweet when you are that person 
> that doesn't know the ins and outs of the system.
> 
> People make choices for other people they cannot understand, or do not 
> understand. Put yourself in someone else's place first, to see what 
> something is like. But many... people lack this ability. Many cannot 
> even write proper documentation because they cannot step outside of 
> their own vantage point (as a developer) (that knows everything).
> 
> And then they say "How am I supposed to know what it's like (being a new 
> user) --, it has been so long for me."
> 
> There is a lot of patronizing going on in thinking you know better than 
> your users, is all I am saying here.
> 
> Regards.
> 
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Yes and secure boot is different for different usecases. I can see secure boot being geniunely useful for an atm on end not that I think there are implementations that use ubuntu that I know about. But if say you boot a malicous live os on the atm then have it empty all of its money that is a problem.  On the other end of the extreme physical acess attacks like this are really unlikely on my desktop in a residental home in the suburbs. I see it as being more likely to be annoying and not provide any useful security on the desktop while it could be useful on the atm. 

-- 
Brendan Perrine <walterorlin at gmail.com>