noauto option ignored in /etc/fstab?

[Josef Wolf]

On Fri, Dec 08, 2017 at 10:47:46PM +0100, Xen wrote:
> Josef Wolf schreef op 08-12-2017 11:07:
> >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.

I've not changed this flag. At least not by intent. I only installed
unattended-upgrades package and set

  APT::Periodic::Unattended-Upgrade 1;

in /etc/apt/apt.conf.

> 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.

So this unattended-upgrades package is of no use at all? Why does it exist
then?

> *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 ;-).

Wouldn't it be better to just wipe the unattended-upgrades package, if it is
of no use at all?

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

The feature to record successful boot? Well, I lived about 25 years without
this feature. Never felt like needing it :-) But those were the days where you
installed lilo manually and had intimate knwoledge of the boot process.
Nowadays, there are myriards of abstraction layers. Guess, nowadays there's no
way anymore to work around boot problems without this feature?

> >>I understand it just seems undoable this way.
> >???
> 
> For me having to type those commands at every boot would be undoable.

Well. Depends how often you boot. In addition, as I described in my previous
post, you don't need this at every boot. In practice, it's about once a month
or something. For me, it's not a big deal to type this once a month. YMMV.

> >>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.

What would this buy me?

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

And I'll have to create a new cd every time grub is updated for EVERY SYSTEM?

Grabbing the next-reachable live-cd (even if it is five years old) looks much
more attractive to me. This is ONE cd for all systems. And I never need to
recreate it.

I don't even need to carry such a cd all the time with me. Many people have
some install cd lie around somewhere, which I can borrow. Only question is,
whether you trust this live-cd, which you haven't created yourself ;-)

> >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.

Now that's really different.

Years ago, hibernate on laptops did not work properly. But nowadays I'm not
noticing problems on this topic anymore. All my non-laptops are runing 24/7.
Never felt like urgently needing this strange standby-thing. ;-)

> >>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.

How that? If malicous grub restores everything before continuing the boot,
you'd never going to notice.

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

I don't carry it around with me all the time. So yes, there are times when I
leave my laptop unattended. That's why I invented this use-case.

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

Undo the leakage of the PW? How that?

> >>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.

But you need to KNOW that it was compromised. And there's no guarantee to
notice this once you executed malicious code.

> >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.

The only way is to always verify code/data before it is executed/used.

This is why TPM was invented. But TPM has other flaws, as you surely know.

-- 
Josef Wolf
jw at raven.inka.de