ccronk wrote on 2024-04-09, 06:57:

I know Fedora is 1. I was wondering which other distros allow booting off of a thumb drive, but to which the native internal hard drive is neither accessible nor even visible.

Isn't knoppix kinda geared toward this?

ccronk wrote on 2024-04-09, 06:57:

I know Fedora is 1. I was wondering which other distros allow booting off of a thumb drive, but to which the native internal hard drive is neither accessible nor even visible.

All so called live Linux distros that can be booted from a USB flash drive or a CD/DVD can be booted and used independently of any OS installed on the local internal hard drive and will not touch the local internal hard drive by default.

See https://en.m.wikipedia.org/wiki/List_of_live_CDs

However, "but to which the native internal hard drive is neither accessible nor even visible" excludes pretty much all of them as they can all be used to access the data on the local drive unless the drive is encrypted or requires a disk controller driver or filesystem driver that is not included with the distro (or available for it).

Not so. I cannot even see my internal drive w/Fedora. Can't. If there is a way to circumvent this, I'd be happy to hear how (not that I'm interested). I produced a bootable drive w/Peppermimt and prefer a non-gnome based gui. But I can see and preaumably alter the internal h/d's contents.

This is almost impossible to achieve - the only way I could see this working is if the kernel was recompiled to remove every possible variation of storage controller and disk subsystem module that wasn't usb.

I cannot think of any standard installer/live cd that would work like this.

You may have a live cd which doesn't do anything with any detected hard drives as standard (IE doesn't try to mount them), but the device tree will still be there from any modules loaded by the kernel and thus dd, fdisk and friends will happily read and write to any supported block devices without issues.

Just alter the kernel line to blacklist the ide and sata controller drivers.

Eg, on the kernel line, add:

modprobe.blacklist=ahci

Which will stop the sata driver loading at all.

wierd_w wrote on 2024-04-09, 08:13:

Just alter the kernel line to blacklist the ide and sata controller drivers.

What, every single variation of them? 😉

Don't forget about the sas and scsi controllers, too, including every possible module.

Remember that you can't just block the high level sata and scsi modules, since a lot of removable devices (which your live cd filesystem could be mounted on) actually talk scsi via usb (UAS). Also is this going to be a usb only live cd, or do we expect our users to run it from cd/dvd too? If the latter then that complicates things massively.

The only conceivable way this could work is if you had a live cd specific to the system you were booting it on, with the storage driver for that particular system removed from the kernel (compiled in or modular).

A one size fits all approach would need so many drivers removed (or as you say; blacklisted - though that doesn't stop anyone manually 'insmod'-ing them later) that it would be infeasible.

Technically, it can work fine if the initrd is never reclaimed...

The squashfs can be inside the initrd, and be wholly inside ram.

Grub uses its own driver to invoke kernel and initrd.

Once kernel is hot, not loading any modules at all for storage devices is entirely plausible.

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

Not so. I cannot even see my internal drive w/Fedora. Can't. If there is a way to circumvent this, I'd be happy to hear how (not that I'm interested). I produced a bootable drive w/Peppermimt and prefer a non-gnome based gui. But I can see and preaumably alter the internal h/d's contents.

While I do not know what hardware you are using and what OS you have on your local hard drive, if your hard drive is connected through SATA or through NVME and if the OS is Windows on an NTFS file system (or Linux on XFS, EXT4, etc), you will be hard pressed to find a modern live distro that would not allow someone knowledgeable enough to access the data (unless encrypted) on the local hard drive and/or write to it or wipe it (regardless on encryption).

That fact that Fedora apparently does not automatically mount the local drive does not prevent someone from doing so manually.

That being said, if you want to limit access to your local drive, you may be able to temporarily disable it in UEFI BIOS, for example.

Why do wish to have the local drive inaccessible ? Is it to avoid accidentally data loss by writing to it or is it more of a security concern about, for example, other people using the computer being denied access to the local drive ?

A 'privacy centric' ephemeral envirionment with 0 persistence capabilities at allmight be justifiable for web based remote work, if traveling internationally to certain countries. (Impounding or searching the system will be completely profitless. There will be no use history at all. Not even atime data.)

Eg, contains only ram based block device drivers, video drivers, sound drivers, and nic drivers.

No usb, no thunderbolt, no iee1394 (if you are using ancient shit...) no scsi, nada.

Mouse might be hard without usb though.

wierd_w wrote on 2024-04-09, 08:28:

Technically, it can work fine if the initrd is never reclaimed... […]
Show full quote

Technically, it can work fine if the initrd is never reclaimed...

The squashfs can be inside the initrd, and be wholly inside ram.

Grub uses its own driver to invoke kernel and initrd.

Once kernel is hot, not loading any modules at all for storage devices is entirely plausible.

Agreed - this method (running entirely from the squashfs image from initrd) would certainly achieve the desired outcome. If this was initially supplied via PXE boot, then no storage drivers have to be supplied at all to the kernel.

If I wanted a true, no-touch, no-impact, live linux system, then this is the way I would build it - serve the kernel and an initrd image from syslinux/pxelinux, with the custom initrd stripped of storage controller modules and the kernel image compiled to not support any. Once unpacked to memory of the client system there would be no means of the kernel populating the device tree for storage controllers or other block devices on the client.

wierd_w wrote on 2024-04-09, 08:28:

Technically, it can work fine if the initrd is never reclaimed... […]
Show full quote

Technically, it can work fine if the initrd is never reclaimed...

The squashfs can be inside the initrd, and be wholly inside ram.

Grub uses its own driver to invoke kernel and initrd.

Once kernel is hot, not loading any modules at all for storage devices is entirely plausible.

If the purpose is to avoid accidentally accessing the local drive, a custom initrd seems like overkill to me.

If there is a security concern about someone having access to the local drive from a booted live distro, one would also need to prevent someone from booting their own distro or rebuilding initrd.

In other words, knowing whether is the an "I want to avoid accidental oupses" or a "let's security harden this" scenario would be helpful.

I don't have any spares thumb drives. All I know is that in the included file inspector app, the internal h/d, which was soldered to the mobo, some sort off ssd, was not visible. Iinm you could't even save anything to the usb drive (download yes but it would just sit there). Can't swear to that though. I've tried this w/3 different laptops, 1 actually had sata spinning rust. And 1 desktop. I think. But I need to try it all again.

Being able to utilize a live linux to inspect a native drive obviously has it's benefits. Which is why I wiped Fedora and replaced it with Peppermint (forgot password on internal h/d). But it's also nice to boot a computer knowing with some confidence nothing will screw wit ur puter during a short web session. Or you need extra privacy for a certain task.

Maybe only Fedora does this? In years past I always utilized a live CD to get me out of some bind. Fedora was the first distro I had used that did this.

megatron-uk wrote on 2024-04-09, 08:36:

wierd_w wrote on 2024-04-09, 08:28:

Technically, it can work fine if the initrd is never reclaimed... […]
Show full quote

Technically, it can work fine if the initrd is never reclaimed...

The squashfs can be inside the initrd, and be wholly inside ram.

Grub uses its own driver to invoke kernel and initrd.

Once kernel is hot, not loading any modules at all for storage devices is entirely plausible.

Agreed - this method (running entirely from the squashfs image from initrd) would certainly achieve the desired outcome. If this was initially supplied via PXE boot, then no storage drivers have to be supplied at all to the kernel.

If I wanted a true, no-touch, no-impact, live linux system, then this is the way I would build it - serve the kernel and an initrd image from syslinux/pxelinux, with the custom initrd stripped of storage controller modules and the kernel image compiled to not support any. Once unpacked to memory of the client system there would be no means of the kernel populating the device tree for storage controllers or other block devices on the client.

Then there is the problem of allowing bootup from USB to begin with.

Secure boot with a custom key would help ( if this system's UEFI allows it). But, assuming the local OS is Windows with secure boot and Microsoft's signing keys, how does one prevent someone chain booting from a Microsoft signed bootloader into another live distro while still allowing Windows to be bootable with secure boot ?

ccronk wrote on 2024-04-09, 08:42:

I don't have any spares at the moment. All I know is that in the included file inspector app, the internal h/d, which was soldered to the mobo, some sort off ssd, was not visible. Iinm you could't even save anything to the usb drive (download yes but it would just sit there). Can't swear to that though. I've tried this w/3 different laptops, 1 actually had sata spinning rust. And 1 desktop. I think. But I need to try it all again.

Being able to utilize a libe linux to inspect a native drive obviously has it's benefits. Which is why I wiped Fedora and replaced it with Peppermint (forgot password on internal h/d). But it's also nice to boot a computer knowing with some confidence nothing will screw wit ur puter during a short web session. Or you need extra privacy for a certain task.

Maybe only Fedora does this? In years past I always utilized a live CD to get me out of some bind. Fedora was the first distro I had used that did this.

No. Be default all live Linux images can alter any detected drives. The reason the USB drive was not writeable is that you are effectively running from an ISO filesystem, and they, by definition, are read-only.

To alter your hard drive, all you would need to do, on any live Linux, is to mount it at a given directory - the 'file inspector app' isn't really where the power of unix/linux is. It's all at the command line, and unless you know what is possible with the basic system commands you will make the assumption that the live system can't access it.

Say you have a sata SSD in your system, with one partition, and your live Linux distro didn't make it writeable, then unless it has Bitlocker encryption making it available to write to would be as simple as creating a folder to mount it on (say /tmp/myfiles), then:

sudo mount /dev/sda1 /tmp/myfiles

... that's it. On every single live Linux distribution that I can think of.

Unless you do something like the driver/boot parameter/module/initrd restrictions we've been talking about in the last few messages.

darry wrote on 2024-04-09, 08:45:

Then there is the problem of allowing bootup from USB to begin with.

Secure boot with a custom key would help ( if this system's UEFI allows it). But, assuming the local OS is Windows with secure boot and Microsoft's signing keys, how does one prevent someone chain booting from a Microsoft signed bootloader into another live distro while still allowing Windows to be bootable with secure boot ?

Absolutely. That is why, in the environment I work in, changes to boot device settings are restricted to system administrators only - when devices are imaged and distributed to staff, they are set to secure boot (usually with bitlocker) and bios/uefi is locked out.

There are too many easy methods to bypass any security of the installed OS when you leave the boot settings open to changes.

Network boot is a less contentious option to leave open, but in the last 20+ years of working for my employer I have seen people come up with all sorts of workarounds (over-riding DHCP settings, running their own PXE/tftp servers on the corporate network, etc)... so even leaving that open is possibly too much of a risk in certain environments.

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

There IS NO HDD.

There is only either a special booter sdcard, or low profile usb drive.

Sdcard can be forced into readonly mode by sending 'dangerous' data to the flash chip or embedded microcontroller, and thus you can further assure that the device cant be altered after creation.

This device is used ONLY to supply the kernel and initrd.

Once started, the envirionment has been neutered to prevent any kind of access to anything sensitive, including the TPM and UEFI parameter data. Nothing. The OS has no facility to read or modify these devices.

Prohibition of loading storage modules would let you use this on, say,a chromebook which has nonremovable emmc.

The REASON, is 'spy espionage bullshit', since corporate espionage IS a thing.

Once started, the ephemeral OS can access and use the internet, so that remote work can be performed. This should ideally include vpn function, and whatever remote storage facilities are afforded, with use of a OTP tokenizer.

The idea is to simultaneously deny:

Any impounded forensics
any offline exfiltration
any kind of persistent tagging
any kind of persistent rootkit function

Etc

There are quite a few fully legit uses for such a deployment.

I wasn't stating there was no conceivable way to access drives. Just by normal channels, open to interpretation depending om who you ask, they're imaccessible. From what I could tell your native drive/os are secure from being fed with. Unless you go downloading some disgusting rot. I suppose an e-mail script could circumvent this. But if all the above is avoided, the native drive/os is invisible to basically everything.

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

I wasn't stating there was no conceivable way to access drives. Just by normal channels, open to interpretation depending om who you ask, they're imaccessible. From what I could tell your native drive/os are secure from being fed with. Unless you go downloading some disgusting rot. I suppose an e-mail script could circumvent this. But if all the above is avoided, the native drive/os is invisible to basically everything.

It's really not. If you limit yourself to clicking buttons in a GUI, sure. But the underlying drives are certainly not invisible to everything - they're just not mounted by default.

If the intention is to use such a system on a personal basis to do stuff that doesn't impact anything installed on those drives, then it's perfectly fine - but please don't make the assumption that the drives are in any way 'protected'.

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.