How are all public computers (libraries, etc.) not full of malware?

Question

How are all public computers (libraries, etc.) not full of malware? Are they protected in a specific way that makes them safe to utilize?

Answer 1

First things first: never assume a public computer isn't full of malware! They aren't always, but a lot of them are. Using one for anything sensitive is generally a bad plan. Even if they don't have malicious software, they could have a hardware keylogger or other monitoring that can capture whatever you read or input.

Now, onto techniques for trying to keep them from getting that way:

EDIT 1: This list is not intended to be comprehensive or go into all the details, and deliberately avoids mentioning specific software in keeping with site guidelines.

EDIT 2: Thank you to the commenters who made helpful suggestions and nitpicks!

• Regular (e.g. daily, or even after each user) OS re-installs. You set up a read-only image that the system can be reinstalled from (it might be on a network, or on an invisible and read-only storage partition, etc.), and whenever you want to reset the machines, you reboot into a mode that reformats the OS install volume and re-images the system, resetting the OS (and all desired software) to the desired state from the read-only image. If that image is on the network, you can even easily update the image (change the default software, install patches, etc.) from a single location. Even with unattended installations this approach might be less convenient (or at least take longer) than some of the others, but it's quite secure so long as the reinstall source is in fact read-only to the users, and nothing prevents the machines from being reimaged as needed. (Depending on the environment, you might really want to do this between each user, even though it takes a little while).
• Limited privileges. If the user can't modify installed software or change system settings, this reduces the harm they can do. It's far from foolproof even if you assume the OS security is bulletproof, though; users can still make changes within the user account (e.g. installing a browser extension) that will compromise future users. Additionally, you have to assume that an attacker with physical access can find a local elevation-of-privilege vulnerability at some point. This is often a good idea to combine with other approaches; most users don't actually need privileged access on a public computer, and it provides defense in depth by limiting the available attack surface for bypassing the other control(s). The logical extreme of this is "kiosk mode", where the computer loads a specific program (which is not a general-purpose shell) when you log in, and that software has very restricted abilities. Kiosk mode is great for single-purpose "kiosk" systems (e.g. a check-in portal at a hotel, or a maps-and-information portal in a mall), not so much for general-purpose computers though.
• Throw-away guest accounts. If the OS treats the user account, and all files created by processes running under that account, as temporary and deletes them when the user logs out, then you don't even need a full reboot; simply ending your login session (which many public computers do automatically) is enough to reset the machine to the state it was in before the last user accessed it. This feature is generally available, through either built-in functionality or third-party software, for most operating systems. It's got weaknesses of its own, though. The user needs to log out, not just lock their session (or deliberately do something malicious, like start a new, non-interactive session as the guest user; some OSes allow this and it might not be apparent to the admins or other users that a session is still running). The OS needs to delete everything the user did, not just e.g. changes made within the user profile directory; this generally means you can't have any local files that are writable by users but outside their profile location. And again, it comes down to the OS' user trust boundary; if an attacker gets local EoP, they can make changes that won't be reset.
• Throwaway virtual machines. Rather than just the user account being a throwaway, the whole OS is a virtual instance of some saved OS state (a virtual OS installation image, or even a saved snapshot of a running VM). You can make it so changes don't persist through a reboot by default, or so that they do but don't modify the saved state they were created from so reversion is always possible. An admin (with access to the hypervisor host/manager) can at any time end the current VM, reset it to the known-good state, and restart it. Admins can also start the VM, make changes they want to keep (e.g. installing new software or updates), and then create a new checkpoint/update the existing one to this new state. Defeating this requires bypassing the hypervisor trust boundary - possible in theory but such exploits are rare and difficult, unless you can physically open up the computer to mess with it - or compromising the admins' ability to update the VM snapshot. The VMs can even be all generated from a single base image, making it easy to update the whole fleet.
• Fully read-only persistent file system plus RAM disk (or other ephemeral storage) for temporary data. In this approach, the user can't make changes that persist past a reboot because there's nowhere that can be written to which is on persistent storage (unless they e.g. plug in their own removable drive, of course). There's a few ways to do this - you can have a read-only OS image plus a writable in-RAM overlay or "union" filesystem (this is how e.g. Linux "live" OS images work), or you can simply have the whole OS install be truly read-only and use a separate directory/drive for (ephemeral) writable storage. This approach of course requires that the user not be able to make the install image read-write rather than read-only, but there's multiple ways to do that too. You can do it in software at the OS level (mount the OS volume as read-only) and hope the user doesn't have a local EoP, you can do it in system firmware (mark a device as read-only) and try to ensure the user doesn't have the ability to make changes to the firmware configuration (e.g. by setting an admin password on the setup utility), and/or you can do it at the hardware level by physically disabling write access on the OS install media (make sure the user can't e.g. physically pull out the SD card and toggle the read-only switch). You can even combine those methods. You can also make the machines boot off of a network image (without write privileges to it). Admins will of course want some way to write to the OS system image, so they can make changes, but it's OK if this requires e.g. a physical key to open up the case and re-enable write access (in the netboot case, it's trivial, and as an added bonus you can upgrade many machines at once).

Answer 2

Just share my example here.

Our student club manage "kiosk" machines in our campus library, and our solution is network boot + prebuilt images + tmpfs overlay. These kiosk machines have their internal drive (HDD or SSD) removed and everything but "IPv4 PXE boot" removed from their boot options. Our PXE server also sends customized boot options for these machines so only the customized OS is available.

When these kiosk machines boot, they pull our squashfs image (~700 MB) into RAM and combine it with a writable tmpfs with overlay2. This is all done in initramfs so normal (userspace) system behaves identically. The OS image is based on Debian and boots into a "regular" (UID 1000) user automatically, launching any predefined applications upon login. We also install a crontab to reboot these machines at 4 AM Saturday morning to ensure they get updated regularly whenever we push new config or images to our PXE server. This also helps get rid of any possible leftovers from normal use throughout the days.

Security-wise, the regular user has no shell access (its login shell is set to /bin/su so you need root password) and very limited network access. There's an iptables/ip6tables whitelist for this user so only library-related websites and services are accessible.

Answer 3

@CBHacking has given a comprehensive answer on how to protect these systems.

What he doesn't touch on is that public systems are often purpose-specific. The library computer can browse the Internet and search the local library catalog and that's it. Limiting what the machine can do makes it possible to lock it down in ways that a machine for general-purpose use couldn't.

If you can tell me exactly what you want the machine to be able to do, I can configure it so that it does that and only that. (I've done that)

There's plenty of technical ways to do that, from application whitelisting to policy-based RBAC/MAC systems.

Answer 4

They aren't, safe to use that is.

How are all public computers (libraries, etc.) not full of malware? Are they protected in a specific way that makes them safe to utilize?

Bold of you to assume that public library computers aren't full of malware. I wouldn't be willing to make that assumption, I don't think you should either.

Banks strongly recommend against logging into their websites from a public computer. And if you do so you can lose a lot of consumer protection against fraudulent activity.

The top 20 google results if you search for "can I access my bank website from a library computer" can be summarized as "don't log into anything that deals with finance from a public computer".

The best way I have heard public wifi/publicly accessible computers described is "They are a PVP zone"... Which is to say that everyone is out to get you/is your enemy. You might get lucky and no one attacks you. You might not and end up losing all your loot.

TLDR: Be safe don't access sensitive websites (financial websites, email that serves as your recovery email, etc...) from public computers/networks.