6 ms·

NanoBSD would be easier to audit than anything Linux based. Once it's booted, you can physically disconnect the write pin of your storage device. If you can man

NanoBSD would be easier to audit than anything Linux based. Once it's booted, you can physically disconnect the write pin of your storage device. If you can manage to dump the contents of it externally to the host, you can then compare checksums to see if anything has been compromised.

bradyd 12y ago
> Once it's booted, you can physically disconnect the write pin of your storage device. Does this mean it requires someone on site to boot the machine? I could see that might not be an issue for ATMs, as they are usually located near banks. It might be an issue for remote locations, though.
- TD-Linux 12y ago
  You can use a write-once hardware register at the end of the boot sequence for similar effect. But you can actually just leave the entire sector write only, even on boot. This is what most embedded Linux systems do - the entire rootfs is read only, /tmp and the like are on a ramdisk, and only a small writable partition remains for things like logs. In fact, Linksys routers didn't even have a writable filesystem - they stored all their settings on a separate EEPROM.
  - brokenparser 12y ago
    > You can use a write-once hardware register at the end of the boot sequence for similar effect. Or use a turn-key switch. First put it into II, wait for the boot sequence to complete, switch back to I. Yes, that does require someone to be on site but that tends to happen anyway when someone restarts the ATM in the first place. If you want to update the software remotely, you could download it into ramdisk and run it from there. For the base system, you'll want something robust so it's more or less guaranteed to get to the point where you can manage it remotely. And you could verify the downloaded application bits against a locally installed root certificate. The old MS-Windows-based ATMs may be rebooted daily, but let's face it, that's just because Windows. When the base system has to be updated for some reason, a service technician will have to physically replace the storage device for it. If that happens very often, they're either doing it wrong or I'd recommend against such a setup. But perhaps the vendor can charge for the service, in which case /care ;) Or they could turn the key into II every last Monday of the month for example (the ATM would go into maintenance mode) at a certain time and let the big maintenance server do its work overnight, avoiding the situation altogether at the cost of a slightly greater risk that the machine becomes defective. In any case, a tiny embedded OS would be perfect for the job.

bradyd 12y ago

> Once it's booted, you can physically disconnect the write pin of your storage device. Does this mean it requires someone on site to boot the machine? I could see that might not be an issue for ATMs, as they are usually located near banks. It might be an issue for remote locations, though.

TD-Linux 12y ago
You can use a write-once hardware register at the end of the boot sequence for similar effect. But you can actually just leave the entire sector write only, even on boot. This is what most embedded Linux systems do - the entire rootfs is read only, /tmp and the like are on a ramdisk, and only a small writable partition remains for things like logs. In fact, Linksys routers didn't even have a writable filesystem - they stored all their settings on a separate EEPROM.
- brokenparser 12y ago
  > You can use a write-once hardware register at the end of the boot sequence for similar effect. Or use a turn-key switch. First put it into II, wait for the boot sequence to complete, switch back to I. Yes, that does require someone to be on site but that tends to happen anyway when someone restarts the ATM in the first place. If you want to update the software remotely, you could download it into ramdisk and run it from there. For the base system, you'll want something robust so it's more or less guaranteed to get to the point where you can manage it remotely. And you could verify the downloaded application bits against a locally installed root certificate. The old MS-Windows-based ATMs may be rebooted daily, but let's face it, that's just because Windows. When the base system has to be updated for some reason, a service technician will have to physically replace the storage device for it. If that happens very often, they're either doing it wrong or I'd recommend against such a setup. But perhaps the vendor can charge for the service, in which case /care ;) Or they could turn the key into II every last Monday of the month for example (the ATM would go into maintenance mode) at a certain time and let the big maintenance server do its work overnight, avoiding the situation altogether at the cost of a slightly greater risk that the machine becomes defective. In any case, a tiny embedded OS would be perfect for the job.