Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some more hardening #50

Open
Rafiot opened this issue Feb 10, 2017 · 5 comments
Open

Some more hardening #50

Rafiot opened this issue Feb 10, 2017 · 5 comments

Comments

@Rafiot
Copy link
Member

Rafiot commented Feb 10, 2017

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

@moshekaplan
Copy link

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
Copy link
Contributor

dputtick commented Feb 10, 2017

@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
Copy link
Contributor

@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
Copy link
Member Author

Rafiot commented Feb 11, 2017

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants