noauto option ignored in /etc/fstab?

[Xen]

Josef Wolf schreef op 08-12-2017 11:07:

> Ah! Now THAT'S a really useful information:

>         "local-fs.target"->"boot.mount" [color="green"];
>         "unattended-upgrades.service"->"boot.mount" [color="black"];

>    Color legend: black     = Requires
>                  dark blue = Requisite
>                  dark grey = Wants
>                  red       = Conflicts
>                  green     = After
>   root at bu201:/#
> 
> Looks like unattended-upgrades.service and local-fs.target are pulling
> boot.mount?

"After" does not pull it in. Only the "black" lines pulls it it.

(I could say unattended-upgrades again ;-)).

> So I've executed "systemctl disable unattended-upgrades.service" and 
> now /boot
> is no longer mounted after reboot.
> 
> So you were right all the time.

Well that's why I was slightly annoyed ;-).

> Guess, I should file a bug against unattended-upgrades package, since
> /lib/systemd/system/unattended-upgrades.service is part of this 
> package?

Well the oddest part about it is that this feature is by default turned 
off:

//Unattended-Upgrade::InstallOnShutdown "true";

By default it is false.

So it doesn't even *do* anything on a default install, it just sits 
there being loaded and running and not activating anything in actuality.

So this service has no impact on unattended-upgrades being installed on 
a default system.

It purely exists for when you toggle that flag.

In fact the actual normal updates and upgrades get done though the 
"apt-daily" service and the apt-daily-upgrade service and their 
associated timers.

The "update" service runs at a random time twice a day, and the upgrade 
service appears to run within one hour after the update service, 
possibly also twice a day.

Therefore you probably don't need unattended-upgrades.service and it 
only exists in case you enable that option.

"Just in case".

Is it a bug? It's more systemd's fault for having a crappy design, 
basically.

You cannot specify that /boot needs to get mounted for ExecStop.

I have no clue how to start a service at shutdown, I'm not even sure it 
is "theoretically" possible.

*Maybe* you could create an interim service that runs all the time but 
does not pull in /boot, that then executes unattended-upgrades when *it* 
gets shut down ;-).

But that's more of a hack than anything supported.

You cannot specify in systemd what you want.

Except by manually mounting /boot.

So you have to remove /boot from the service definition like I said.

And then execute the mount as part of ExecStop, but nobody practically 
uses this like I said, it is just a feature that exists.

On the other hand your grub feature might also stop working, it 
basically assumes /boot is mounted.

> Now, how would I run unattended-upgrades manually?

You don't need it like I said, if you don't have the shutdown thing 
configured.

> /lib/systemd/system/unattended-upgrades.service only has an ExecStop 
> entry,
> but no Exec entry.
> 
> Is it OK to run /usr/bin/unattended-upgrade directly from cron?

It probably doesn't do anything on your system. "apt-daily-upgrade" does 
your thing.

> No. It resolves the possibility that someone would mess with your 
> laptop when
> it is powered off at home while you're at work.
> 
> 
> Depends how often you boot. Myself usually boots only when some upgrade 
> tells
> me that a reboot is required.

> Good to know! I always hated those camel-case keywords. How on earth 
> can
> someone come up with such braindead camel-case keywords for the command 
> line?


>> I understand it just seems undoable this way.
> 
> ???

For me having to type those commands at every boot would be undoable.

>> Do you realize you could probably burn Grub to a CD and then boot from 
>> the
>> CD?
> 
> I know.
> 
> But this has two disadvantages:
> 1. I would have to maintain my own boot-cd instead of just using one of 
> the
>    billions of already existing live-cd.
> 2. I would need the cd on every boot. With the current setup, I can 
> safely
>    skip the verification step when I know for sure that nobody had 
> physical
>    access to the laptop during the power-off. For example for a quick 
> reboot
>    or something.

You can still do that because you can install Grub in as many places as 
you wish.

Update-grub does not actually impact the grub bootsector/core image.

> No. I just don't boot that often. Granted, the days when uptimes were 
> measured
> in years are long gone. But we still don't need to boot on a daily 
> basis.

I shutdown my system because all of my recent motherboards have had 
failing standby/hibernate (also in Windows btw) and I do require 
standby. So barring that, it goes off more often.

> BIOS protection won't prevent an attacker to take out the disk for a
> manipulation.

Yes I know, it just determines the amount of risk you are exposed to.

>> No I meant that I was not considering a high-risk situation in which
>> directly after booting you could get compromised.
> 
> The compromise needs not to take place directly after the boot. The 
> attacker
> can wait until you're at work again.

In that case you would already know your machine had been compromised.

Why would you leave the laptop in an unattended state at that point?

It also means your scripts have plenty of time to undo the damage.

>> Of course it would be extremely hard to immediately trace the location 
>> where
>> the modified grub would have written its data,
> 
> It could even have been sent over the net.

That's true. At that point you can change your password and the attacker 
is void again.

>> You could immediately verify grub while in the initrd and take 
>> measures, but
>> it would have to be automated.
> 
> Malicious grub can restore original grub once it has harvested your 
> password.

I... didn't consider that ;-).

I guess you've beaten me there ;-).

> I don't see how you would get a reliable solution without verifying 
> BEFORE
> executing.

I succumb.

> Malicious grub could send your PW over the net and restore the original 
> disk
> contents that the attacker stored somewhere on the net. Then it 
> continues the
> boot as usual. Your verification would not notice any changes.

I guess it is not theoretically possible to defeat that.

Well I can think of a dozen measures but it remains a cat and mouse game 
this way.