0

Good day, I am currently planning an environment where it comes down to the biggest security risk being to boot to another environment and tamper with the install on the disk (Older PCs with physical access to the box that are accessible to the public). Since BIOS passwords offer little deterrent and the PC's don't have TPM to best of my knowledge, what would you recommend to make the install tamper-proof? I am currently thinking full block device encryption (LUKS) that includes the /boot folder - should this be enough? This way even though you are able to boot up to another device the install disk shouldn't be a problem, correct? Thanks in advance

EDIT: Just to clarify, the PC's are under surveillance and in cabinets- so attaching a hardware keylogger won't easily go unnoticed. Booting to a USB and tampering with the install - this is the big problem. Advanced attacks like modification to the BIOS/UEFI firmware probably won't happen (school environment) - software keyloggers being the big worry.

EDIT2: Further clarification - the PC's are in a cabinet like so:
------------
|Desktop PC
------------

With the top part covered. The keyboards are plugged in at the back, so to access the keyboard USB you would have to remove the whole desktop from the cabinet. The surveillance is not constantly monitored but should a keylogger be found (or a security breach) it would be very easy to see where and when this happened (identification is not a problem since it is a school environment, as for calibre of attackers advanced attacks shouldn't be a problem, more likely is the casual keylogger and modifying install). Since the surveillance is not to the extent where activity on the screen can be monitored booting to another environment and working there can go easily unnoticed. The proposed environment is a Linux install running a non-persistent Windows VM - so an OS exploit shouldn't be a problem from inside Windows and the Linux install would be running a non-privileged user, so damage is limited to almost nothing. But, if the Linux installed can be tampered with before boot up all goes to hell. This is why I see preventing tampering with the Linux install as the biggest problem.

Cube777
  • 1
  • 2
  • Did you think of just detaching the USB from the mainboard? As there are old like you said they could just use PS/2 for Keyboard and mouse probably. Still possible to tamper with this, but more unlikely. – Matte May 14 '16 at 12:54
  • @Matte Thanks, interesting solution - will think about this – Cube777 May 15 '16 at 08:58
  • It is not clear from the question why hardware keyloggers (which can be really stealth) are not considered a threat while booting from USB is, because both should be noticed when PC's are under surveillance. Also it is not clear why booting a different system or tampering with the install is considered a great risk while privilege escalation by using a OS exploit is not considered. It might help if you describe the use case in more detail, i.e. is it more like a kiosk system where no user data are kept between reboots or is it more a workstation. And what knowledge you expect from attackers. – Steffen Ullrich May 15 '16 at 09:11
  • @SteffenUllrich OP updated, hope I provided enough info. – Cube777 May 15 '16 at 09:48

2 Answers2

2

It is probably not possible to make this system tamper proof, at most you can make at some level of tamper resistant. Full disk encryption is a good way and maybe even the best you could achieve with off-the-shelf PC hardware.

But disk encryption does not help against simple hardware key loggers which can be used to get to the disk password. More advanced but possible are modification of the firmware, i.e. BIOS/UEFI, disk, network card, graphic card, Intel SMM ...

In summary, you cannot really build a skyscraper (i.e. tamper-proof) in a swamp (off-the shelf PC).

Edit: based on the updates to the question it looks like that everything which need to be done is to make sure that the system only boots the installed Linux without user specified arguments (i.e. no init=/bin/bash). This can be done by restricting boot medium in the BIOS, protecting the BIOS with a password and protecting the Linux boot loader (grub) with a password. Disk encryption will not help here and in fact hinders unattended boot of the systems which is probably required in this environment.
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for highlighting the more advanced attacks - I've clarified my OP, please have a look – Cube777 May 15 '16 at 08:55
  • @Cube777: with the updated requirements the solution should be much simpler, see edited response. – Steffen Ullrich May 15 '16 at 10:34
  • Correct me if I am wrong, but won't bypassing the BIOS password still be a problem? – Cube777 May 15 '16 at 13:22
  • @Cube777; BIOS passwords can usually bypassed only if they are weak or if the user is able to reset the password, usually by removing the battery from the hardware for some time or setting some switch inside the computer. If the user gets that far and you don't notice then the user can also install a key logger and you wont notice. – Steffen Ullrich May 15 '16 at 14:14
  • @Steven And factory reset passwords? In a quick Google search there are various mentions of "generic" factory passwords - are these still relevant today? – Cube777 May 15 '16 at 14:43
  • @Cube777: You have to check with your hardware if it is affected by generic passwords. Apart from that you can also lock the computer away and expose only mouse, keyboard and monitor so that the user will not be able to insert something to boot from. – Steffen Ullrich May 15 '16 at 15:18
  • @Steven Thanks for all the help, I will check - if they are affected, I'll go with the full block-device encryption (automatic bootup is not a problem here). – Cube777 May 15 '16 at 15:59
0

if no service needs to store data, you could make a read only disk. but if people have physical access to the machine, you are pretty much screwed.

user110619
  • 9
  • 1
  • The PC's will have to be actively used + updated - this won't be a viable option (and this will also probably be software implemented which won't help) – Cube777 May 15 '16 at 08:56