Could placing binaries on write protected media be a thing?
Installing tripwire one of the install screens advised about storing binaries on write protected media.
How would one go about placing let's say one or a number of critical binaries on a write protected MC card (and have them reachable by the running system)? Remote tampering would be impossible this way.
Sorry if it is a trivial thing to do, and thanks for the ideas!

Yes, it's exactly what Android does. Very easy to do.

You can put whatever you want on any filesystem, not necessarily a removable one, and mount it read only.

Mounting read-only does not prevent altering the files if there is physical access, or even remote access. With the proper access, the filesystem could be remounted read/write, altered, then remoounted read-only again. If there is no physical access, the lock switch on an SD card would prevent remote access, but anyone who can get physical access can just move the switch. The only way I know of to do this is to use optical media - write to a CD or DVD and finalize it. But depending on the paranoia level, any of the above could work. With the proper security, just mounting read only could be sufficient. It's all a matter of having sufficient knowledge and motivation.

1 members found this post helpful.

Proper access being the key words here. It's going to be as secure as you make it, but there are 3 simple steps you can follow to make it significantly more secure:

Set up a secure root password, don't share it with anyone, and, most importantly, don't run as root.

1 members found this post helpful.

I would like to point out that even if you assure that your device is read-only in hardware, this still does not make your device tamper-proof, anyone with enough access to attempt to tamper with binaries on your device would likely be able to simply mount another file system over top of your read-only mount point. Even if you ensure that the device _only_ has read-only hardware, a tamperer could simply mount a tmpfs and put whatever they want there.
In other words, you can (using hardware) guarantee that your binaries are not tampered with, however, this does _not_ guarantee that the binaries you invoke will be the same ones on the device.

A strategy like this may work on some systems, but it requires a very restricted system, one where even the device admin does not have this kind of access.

Thank you all for the thoughts!

I am aware of the different scenarios and threat levels (regarding physical access and so on). In my case accessing the machine from the network is the threat level. A good root password of course is necessary, but what I would like to achieve is to have binaries that need physical access to be modified. I'd start from here, and work my way up to different other methods of protection. Luckily I am not really any kind of interesting target, just a plain home user (and probably easy to guess that not with much sensitive data).

Is it called symlinking? What is the keyword I need to look for to learn about how to have my/some binaries in other places than the default install locations? Say, for example I would like to place the /bin/bash binary to /media/user/MCcard/binaries (I'm on Debian) and be invoked from there - how do I do I go about it?

Thanks again!

I guess using a squashfs-formatted root partition could provide a little more guarantees that the filesystem contained won't be modified (IIRC it's read only by design).
As others said, however, a motivated attacker with access to the system could be able to mount anything over it (i.e. this is what is normally done in OpenWRT systems, squashfs root partition + overlayfs writable data partitions), rendering the whole "system on a write protected media" security argument useless.

A symbolic link (symlink) is basically the same as a shortcut file in windows if you are familiar to that. Its a file that just contains a reference to a file in another place. Yes, you would need to do this if you still plan on pursuing this, although IMO you gain very little security from such an endeavour. You will need to be aware, however, that (depending on which executables are located on your read only volume), this may complicate your boot process. If, for instance, you move all coreutils (or busybox) binaries to your read-only volume, then your symlinks will be broken when /media/user/MCcard/binaries is not mounted, and without the mount utility, you may not be able to mount the needed volume.

Historically, something like this scenario was a common problem, since many users kept /usr on a separate partition, and /usr/bin could contain binaries that were needed at boot time. This is generally not an issue any longer since nobody feels the need to do this anymore.

Now if you use an initramfs or initrd in your boot process, these could be used to mount your read-only volume, but how you do this depends on how your ramdisk is created (I don't know, I don't use a ramdisk in my boot process).

IMHO it comes down to sufficiently securing outside access to the system.

Additionally, look at how Android is doing these things. It probably won't get safer than that, at least technically (Android is unsafe for other reasons).

That's what Puppy Linux does with its live CD.

That's what every Linux distro does with its Live CD.

your drivers are made in china

too bad if one tick on one clock cycle in one chips is "tweaked right" that your chip has a back door in it that triggers normally quiet circuit to "do a job"

think of security that way

Linux From Scratch (or XLFS's bash scripts) can show you how to create a linux OS on a disk, if that
s what your asking

but there are simple utilities to make linux OSes on a USB so you can't be asking that

what are you asking?

-----------------------------
symlinking ... hmmm, or ld (hard or soft links are both links)

do you mean "jails" from freebsd? sandboxes from (google, apple) ?

yea you can easily do "ln -s" on an OS tree into a tree you'll later make read-only (and your OS must support using the bits on the links not the destination files though - careful - does your kernel respect the top level directory bits or the bits on the symlink (on linux, i think, no, yes - but check))

you could then "chroot" (or pivotroot) to that tree ... and without LFS and some reading have some issues about not being able to log-in to your new OS disk because it it's disk cannot be written to (which is easy to fix, if you know how)

-----------------------------
TRIPWIRE IS OLD SCHOOL I CAN TELL YOU WHAT THEY MEANT TO ADVISE YOU UPON

* websites used to be available to the public on WORM CD media (read only media, so an attacker couldn't, say, take down Solaris.com or Yoohoo.gov) - they could cause a need of reboot at best but not "loose the website"

* HARD DRIVES (and some USB) have a write protect feature (a jumper). you would put all files on your server that shouldn't be altered and bump the jumper

* yes, root protection and read only bits "are supposed to work", but experience is that will get hacked if it is "a site on the internet open to the public".

-----------------------------
DO NOT put anything you much value on a PC unless you have scissors for the network cable and have damaged the wifi antenna. It Is Not Secure.

For example: did you know your cable modem (gov dessign "DOCIS") allows your cable company to watch what your doing on the web live as you are doing it? if you didn't ... well now you know.

WARNING by someone who's had to use a rescue disk

IF you change your /lib or /bin or /sys "read only" it may bite you.

You don't know if "ubuntu" writes there during boot time (if it does, you may get frozen out of booting) (hey - rules aren't for big maintainers)

ALSO - if you upgrade and your bins are read-only, you'll end up having 1/2 an update (surely that could freeze you out of your PC)

-----------------------
WARNIGN: also - MOST LINUX DISTROS have a "trap" which prevents /lib from being accessed from anywhere except /lib (and there's a way to remove that but it requires some work be done, xlfs does this). so: if you tried to tell "ld" your /lib is in /foo/readonly/lib, and then moved your libs there? bash would mv the files and you'd be locked out and getting "nasty messages". it also inhibits testing new software and new systems or competing linux unless you go the whole 9 yards to make a whole OS disk (enough about that for now), AND prevents having "fall back libs" (incase the experiment fails, unless your in a chroot OS and fall out of that back to /lib)

-----------------------
POINT: do a backup before you go messing with your system files and be prepared to use it (ie, have a boot disk that works, know how to get your backup onto the disk, etc)

ANOTHER TIP: modern systems have "extended security" (beyond user and read/write bits on files)

for example, on an apple computer no one can write to /bin except the apple installer during upgrade, not even 'root'. you have to reboot the computer to be able to "run as root", but even as root you can't clobber system files.

with modern linux KERNEL: root is not the "real root" either (root cannot write to anywhere in memory), you can write to system files (but if you compiled a custom linux kernel, you could lock that out)

so ... you may be ok without "physically locking your disk". all depends you know? that advice ... that's pretty old advice. surely it's good if you think "yea, if i get hacked i can still reboot, but i lost all my user files"

but on a modern IBM or amazon cloud, it runs many OS side-by-side (server hosting) "where each customer/server can't attack each other locally" ...

So i would say in the end ... cloud hosting: good. Write protect your disk: old technology but maybe useful if you leverage it well (ie, can boot after disaster, loose no content, be online as quick as loading a backup, etc)