noauto option ignored in /etc/fstab?

[Xen]

On Wed, 6 Dec 2017, Josef Wolf wrote:

> I am not ignoring you. In fact, I have actually replied to one of your mails.
>
> I don't see why unattended-upgrades needs /boot to be mounted ALL THE TIME. It
> needs /boot to be mounted DURING THE UPGRADE. And in my reply to your mail I
> have shown how this can be achieved.

Sorry didn't see that, but are you saying that you already solved the 
mount problem?

I am not certain unattended-upgrades is not started at boot. Most systemd 
services run for the entire duration of the system, so I supposed this was 
the case here too. So on my system, since boot 11 minutes ago, 
unattended-upgrades is *running*.

Even though I have disabled it in /etc/apt/apt.conf.d

And in fact it hasn't actually run since I disabled it; but that aside, 
the service is still running.

This service is also still pulling in boot.mount regardless of what it's 
doing.

So unless I am mistaken here and you have already solved the issue,
as far as I can see your boot will be mounted until you disable 
unattended-upgrades.service.

But maybe the suggestions by Tom have already solved it?

Here is the file:



[Unit]
Description=Unattended Upgrades Shutdown
After=network.target local-fs.target
RequiresMountsFor=/var/log /var/run /var/lib /boot
Documentation=man:unattended-upgrade(8)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
TimeoutStopSec=900

[Install]
WantedBy=multi-user.target



This is not conditional. If this service is running on your system now, it 
will have pulled in boot.mount at bootup.

This service apparently only runs at shutdown (I mean that it only 
executes something at shutdown) but that still means it will be loaded at 
boot.

Systemd does not have any facility for loading services only at shutdown.

All shutdown services get loaded at boot and do nothing in the meantime.

So there is no facility to only "start" it when it is needed.

Yes during sysv you could run a script only at shutdown, no longer so.


So what you can do to solve your problem is this:

sudo cp /lib/systemd/system/unattended-upgrades.service 
/etc/systemd/system
sudo sed -i "s@ /boot@@" /etc/systemd/system/unattended-upgrades.service



> While this gives you an encrypted /boot, it won't buy you anything above an
> unencrypted /boot. An attacker would simply modify grub to store the key
> somewhere unencrypted.

Grub doesn't store the key. You mean the initrd?

Do you mean a physical attacker or a digital attacker?

> To prevent the attack, you have to make sure that you
> never execute something that might have been manipulated. With encrypted
> /boot, you have still to check grub.

That implies there would be another location on your laptop where a kernel 
and initrd can be stored, at which point the digital attacker has to rerun 
grub-install (or update-grub) with a different location to mount from; 
which would have to be encrypted with the same password, but your attacker 
doesn't know this password.

Hence, your attacker could never fool YOU.

Unless perhaps the headers of your /boot partition were to be copied 
verbatim, and your boot partition was first copied, then unlocked using 
the key, then the boot files modified, then update-grub/grub-install run 
from/with this new boot partition.

There would now be a second boot partition on your physical harddrive.

A LUKS password unlocks a header key. These header keys give access to the 
master key.

You cannot derive the password from the header key so easily, so the 
keyfile cannot be used to change or manipulate the master key, nor can you 
replace the passworded header key.

Thus, the second boot partition now has to use the same master key, 
essentially a duplicate.

This means that a *physical* attacker can never do this. Your digital 
attacker first has to obtain, or modify the running system, your keyfile.

But if they can modify the runtime initrd, that means Grub is out of the 
picture; they don't have to change Grub, changing the kernel or initrd or 
modules is good enough.

So grub is not an issue here, it cannot be used for an attack:

1) a digital attacker doesn't need it
2) a physical attacker can't use it.



> Encrypting root and everything else except /boot is supported out of the
> box. Getting encrypted /boot adds a lot of additional complexity to the
> install process.

I understand that your current solution exists outside of the main system, 
thus the main system is unmodified. I mean it is not a bad system or 
anything, it is actually pretty cool.

> And it buys you nothing, since you still have to check that
> the (unencrypted) grub is not modified.

But this is where you are wrong because Grub doesn't store any keys.

No physical attacker is capable of pointing grub to a different location 
that will have the same password.

You have to TYPE IN A PASSWORD. Grub has no knowledge of keys.