noauto option ignored in /etc/fstab?

[Xen]

Josef Wolf schreef op 11-12-2017 23:29:

> I'm talking only about REAL hardware.

Well I just answered your question as to why I considered myself having 
learned something.

The answer to that question lies in the fact that some people also 
encrypt remote systems.

> The install CD?
> 
> I have grown a rake script that
> 
> 1. downloads the server-install-cd
> 2. adds a menu entry to use my preseed file
> 3. deletes some packages which I don't feel like needing
> 4. installs a late-command, which will install a systemd service that 
> is
>    executed when the freshly installed system is booted for the first 
> time.

Oh I thought you would have added the stuff (new packages etc) in the 
installer itself.

But I guess you want the latest versions immediately.

> 5. this "postinstall" script starts a screen session on tty6 and starts 
> four
>    initial windows:
>    - window 0: top
>    - window 1: watch 'hostname -f; echo; route -n; echo; ifconfig'
>    - window 2: watch 'ps fax | grep -v grep | grep -B 5 -A 24 
> postinstall'
>    - window 3: runs the real postinstall script.

That's neat.

What if you wouldn't have network?

> The postinstall script:
> 1. makes sure network is available
> 2. removes cdrom from apt.conf

This thing seems to be bugged...the CD. You have to add it back to the 
index each time if you want to use it :-/.

>> Also I think in my life the risks are different.
> 
> If I can eliminate a risk without any effort, I go for it.

It's not without cost.
But for you it works.

I hide the boot partition because I want the adversary to have as little 
information as possible.

The adversary knows it's a Linux system but does not even know the 
kernel version or the distribution.

This just reduces the room for asking questions. Someone who is faced 
with a blank wall cannot inquire into that wall, or less so.

For instance your boot system probably displays the name of the 
partition that you are about to unlock, including the LUKS name.

The Grub boot prompt is nondescript, ugly (unfortunately) and more like 
TrueCrypt.

There is no clue about partition layout (because there is only one) and 
after I'm done patching LUKS (one day, ever :p) there won't even be a 
partition table.

It will be a Grub bootsector, a LUKS header, some room... and then 
encrypted space.

Or even differently, LUKS headers are not encrypted, TrueCrypt's are.

TrueCrypt encrypts the partition table.

Linux doesn't even need no partition table.

But I dunno.

YMMV.

But anyway I want the adversary to see the least amount of interesting 
possible.

No clue what to find, no desire to find out.

And I think it has served me well in the past :p.

> If there'd be a noticeable effort, I'd step back and think whether it's
> actually worth to do.

Sure but that's only true because you rarely reboot your machines or 
power them off.

Which might mean you don't turn them off because it would incur 
additional effort etc.

> Ugh!
> 
> You mean doing this automatically by a preseeded install-cd?
> 
> I once had set up my install-cd for automatic disk partitioning.

No I never install "simple" systems so I also wouldn't use that same 
feature (repartition or use empty space) for something automatic...

I am basically also still experimenting and every install I try 
something new... This is my first dmraid system :p.

It's the *only* dmraid system you can boot from with Grub ( I think ) 
--- nVidia raid :p.

Not sure about that though.

Could be entirely wrong here.

I'm on dmraid and my root partition is cached too :p.

So I have a RAID 0 HDD system cached by SSD :p.

Using embedded LVM :p.

(I mean one partition contains 2 logical volumes that are actually 
physical volumes for another volume group, and the SSD does the same, 
so...

Both the HDD (raid) and the SSD have a volume group called "coll".

The part that's on the HDDs contains msata-pv and raid-pv and the part 
that's on the SSD contains msata-pv-cache and raid-pv-cache. msata-pv 
and msata-pv-cache combine to form in this case a cached root.

And raid-pv and raid-pv-cache do the same for something else.

So I have a cached logical volume spawned from physical volumes that are 
logical volumes that are part on raid 0 dmraid and part on SSD.

Now isn't that hilarious. And it all works :p.

> That was a really bad idea: It's way too easy to wipe all data by 
> accident.

I understand.

Particularly if you can't even select the harddisk.

And even then...

>> Well, you know, I was only responding because you said encrypted boot 
>> was
>> _not possible_.
> 
> Oh! Then, I correct myself:
> 
> It is not possible to have _everything_ encrypted. And this unencrypted 
> piece
> of code/data is the achilles' heel.

Yes I see this now.

> You're STILL vulnerable as
> long as grub can be modified.

Depends on the form of adversary and in what way will they take your 
stuff.

Certain classes of adversaries will not wait around until you've typed 
your password.

They take your stuff and then find out it's encrypted.

At that point, if they were to give back your stuff, you'd have plenty 
of time to verify Grub (or reinstall it) and even if you didn't, they 
wouldn't be there to steal your password.

And if this risk existed, yeah I guess you would watch your step.

> Right. But automation is not a prerequisite. Those scripts are really 
> trivial.

Right. I know.

> Probably none. But since there's no effort, why not do it? Much better 
> than
> feeling safe just because /boot is encrypted...

Again depends on your goal ;-).

You might even choose not to encrypt anything because you want to show 
the other person that you have nothing to hide.

Encrypting then, would feel very unsafe.

Because sometimes being secretive only raises suspicions.

_Some results may have been removed under data protection law in 
Europe._