Some more hardening - Githubissues

CIRCL / Circlean

USB key cleaner

https://www.circl.lu/projects/CIRCLean/

BSD 3-Clause "New" or "Revised" License

451 stars 70 forks source link

Some more hardening #50

Open Rafiot opened 7 years ago

Rafiot commented 7 years ago

A few things we've been thinking about to do some more hardening on the platform:

The shell of the pi user should be nologin and make sure it still works: https://github.com/CIRCL/Circlean/blob/master/circlean_fs/root_partition/etc/passwd#L23
It would be nice to add /etc/shadow in the repository, and replace the password of pi by * to disable it completely, and make sure no users ever have a way to login.
The block hid rule doesn't work on the old rpi, is it working on the newer versions? https://github.com/CIRCL/Circlean/blob/master/circlean_fs/root_partition/etc/udev/rules.d/50-blockhid.rules

moshekaplan commented 7 years ago

Closer on the side of paranoia, it may be worth segmenting the libmagic code away from the rest, given the possibility of an exploit targeting it. One possibility would be to keep that code in a separate binary and lock down its capabilities with Apparmor or SELinux

dputtick commented 7 years ago

@Rafiot I was planning to test the hid udev rule, I'll do so next week. The implementation looks like it could be somewhat rpi model-specific. There might be a way to block all usb devices that aren't block storage that's a little more elegant than the current rule (using only udev syntax instead of a bash script inside a udev rule). Setting up /etc/shadow seems like a good idea.

dputtick commented 7 years ago

@moshekaplan that's an interesting idea. Do you mean the PyCIRCLean code that Circlean runs using python-magic, or the libmagic binary itself? I think at the moment we're trying not to be too paranoid about attacks intentionally targeting the design of Circlean itself, but if there are easy things we can do to make Circlean more secure that's definitely a good thing.

Rafiot commented 7 years ago

@moshekaplan this is a good point, everything doing parsing is susceptible to be vulnerable to this class of attacks.

Right now, libmagic worries me less than pdf, office documents and unpacking of archived documents. My initial approach to reduce the risks would be tu use apparmor, as it is already present on the image.

moshekaplan commented 7 years ago

@dputtick : It would likely require moving the code interfacing with libmagic to a separate binary, so it could be limited to only reading files and not writing to the disk. I haven't reviewed Circlean's code enough to say anything about implementation.

@Rafiot : Very true.