Not very.

Sctipt just needs bash and superuser access, if it can see block devices.

It might not even need superuser if it abuses FUSE.

ccronk wrote on 2024-04-09, 09:16:

So for arguments sake how formidable would a virus or script need to be to dig down to your native files system? I'm not talking about an operator who has an extensive knowledge of linux.

Well since most live linux distributions automatically give sudo permissions to the default user, all someone would have to do is get you to run a variation of the "sudo mount" command (or anything else which can access the block device with your data on) I pasted earlier. There are a million and one drive-by or social engineering attacks that can take advantage of the escalation of a normal account via sudo (and most live distributions don't even enforce password entry to access sudo).

I've seen countless people blindly paste text from a website into a terminal because "that's what the web site says to do in order to get the widget to work".

So in some aspects, it's less secure than a normally installed system which would typically request your password when running sudo.

I don't blindly paste text into anything.

It sounds that apart from a considerable exploit, the fs is inaccessible.

No. A very simple script can do it. I am on a phone, and doing shell script for-next fancy witha touch ime is a pita, so this is a real niave example.. but this is all that needs made and run, generally.

!# /bin/bash […]
Show full quote

!# /bin/bash

#automatically cover our tracks on reboot! Shhh!
mount tmpfs tmpfs /mnt
mkdir /mnt/.secrethidden
mkdir /mnt/.secrethidden/sda1
mkdir /mnt/.secrethidden/sda2
mkdir /mnt/.secrethidden/sda3
mkdir /mnt/.secrethidden/sda4
mount /dev/sda1 /mnt/.secrethidden/sda1
mount /dev/sda2 /mnt/.secrethidden/sda2
mount /dev/sda3 /mnt/.secrethidden/sda3
mount /dev/sda3 /mnt/.secrethidden/sda4

#now give user access!
chmod 777 /mnt/.secrethidden -R

Now all drives will be mounted and all users can see it.

In the interest of going down the "ephemeral no-trace OS" rabbit hole, I think the idea of a computer with no HDD is interesting. Boot from USB created from an ISO (not a live USB), encrypt memory at boot, and then when the computer is powered off, nothing is recoverable. This would be useful in certain locations for sure.

As far as the "wtf is this" question a foreign actor may ask while you're in such a location, the answer would be to have a HDD in the computer which you remove when you use it.

Pretty cool thought exercise.

In the case I suggested:

Boot from a removable sdcard.

This card contains a cryptographically signed, encrypted filesystem.

It has also had the final memory cell in the array purposefully destroyed, to force the flash controller into read-only mode.

(in the case of a crappy chromebook, this can be the baked on emmc!)

the system then boots from this (hardware level!) read only device, validates the signature against the TPM, and then boots.

The linux image contains the ENTIRE OS as a compressed squashfs container inside the initrd.

The kernel is configured to not have any storage drivers aside from ram-backed ones (tmpfs, zram, etc). These are used to provide /home and pals.

The kernel is configured to disallow any unsigned kernel modules to be loaded.

The kernel uses a custom signing key.

The kernel has all drivers and toolchains for mucking around with MTD, TPM, UEFI, or secure enclave datastores removed. It lacks the capability to access, let alone alter, these devices.

The squashfs container has its md5 sum verified before successful mounting.

The network stack is configured to create a secure vpn channel over a strong ecc enforced connection, with additional verification using a long passphrase, AND user input of a One Time Pad, produced using a hardware tokenizer.

This gives the 'actually authorized' user access to a secured remote datastore outside the exfiltrator's reach.

Proper data siloing is enforced on the remote.

Any browsing data, temporary files, etc, will be 100% lost on poweroff.

In the case of a physical microsd card (again, such as with a chromebook), A cigarette lighter will do the boot media in very quickly, if necessary. A hammer, likewise, will suffice.

Combined with quality 'check in' and 'check out' processes at the remote, this can be very very secure.

wierd_w wrote on 2024-04-09, 09:02:

To me, the "use case" for a 100% ephemeral linux session, is literally:

There IS NO HDD.

yes, in simple terms if i was using linux live and didn't want it to 'see' my hdd i would simply unplug the hdd

i have used lighter linux live variants via usb on machines without a drive, its often surprisingly responsive in use, especially with 4+ gb ram

ccronk wrote on 2024-04-09, 09:16:

So for arguments sake how formidable would a virus or script need to be to dig down to your native files system? I'm not talking about an operator who has an extensive knowledge of linux.

If you've booted from USB the there is a chance that UEFI was infected either by your USB getting infected or the media you loaded to it was or both. Chances of discovery on infected UEFI are slim so reinfection would occur. So make sure you use approved, scanned media and enable secure boot.

Really talking about preventing access to your HD when someone has physical access is kind of pointless.

DosFreak wrote on 2024-04-09, 13:29:

If you've booted from USB the there is a chance that UEFI was infected either by your USB getting infected or the media you loaded to it was or both. Chances of discovery on infected UEFI are slim so reinfection would occur. So make sure you use approved, scanned media and enable secure boot.

Who needs some USB stick to attack their UEFIs when the manufacturers will pre-attack:

https://eclypsium.com/blog/supply-chain-risk- … enter-backdoor/

Basically Gigabyte crapware lurking in UEFI, and if you installed/reinstalled Windows, the crapware would be reinstalled in Windows. IIRC including a web download, over HTTP or HTTPS, but with no security check on the HTTPS. So man-in-th-middle-able.

This very machine had the UEFI crapware, but this mobo has never run Windows. Basically dodged a bullet.

I thought I was cynical to sneer at BIOS interfaces for looking like the UI from a computer game, but it seems that perhaps the vendors made effort in the wrong place? Nah, not our beloved tech-bros, they know best. They keep telling us that.

On the original topic, a bit, in the Linux kernel source tree there is a script that can make a bare-bones kernel config. A config that only has modules that are needed. I used it to rebuild the Slackware kernel for a VM I wanted to make small, and possibly have less chance of being broken into (or out of).
./scripts/kconfig/streamline_config.pl

Possibly this would be of interest..
https://en.wikipedia.org/wiki/Tails_(operating_system)