Ubuntu 16.04 Secure Boot Policy

[Xen]

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.