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@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
