Re:Show HN: Sandy – A tiny Sandbox to run untrusted code ️
by craig on Monday January 13, 2020 @09:41AM
(#22034805)
Thanks for the input, I agree and I've added a warning to the readme taking this into account and directing readers to this discussion.
I do think there is value in ease of use with something like sandy. I'm unlikely to setup gvisor just to run some arbitrary script I found online. I assume most people today just will run scripts directly on their machine. With sandy, I was experimenting if you could get 80% of the security while still making it really easy to use. I agree that it still hasn't met that mark with regards to security but I think it's possible to improve that.
Re:Show HN: Sandy – A tiny Sandbox to run untrusted code ️
by grawprog on Monday January 13, 2020 @10:55AM
(#22035506)
>With sandy, I was experimenting if you could get 80% of the security while still making it really easy to use
This seems dangerous. That 20% insecurity is still pretty large, but small enough it makes users complacent and gives them that false '100%' secure feeling, especially when coupled with ease of use.
Poignantly, the naive approach of 'let's just block read(2) to prevent file access' doesn't work - there's multiple ways to bypass simple read(2) filtering like this. The easiest that come to mind are:
The same applies to any other policy you wish to implement, and for every one of those you need to consider the collection of all Linux syscalls and filter all of the relevant ones. There's around 300 syscalls in Linux as of writing.Not to mention typical newbie mistakes that this project makes: not following forks, not checking for 32-bit syscalls, etc.
gVisor [1] does this well - instead of filtering, it reimplements the logic for handling Linux syscalls in userspace (eg., is actually responsible for handing out FDs and other handles, presenting the filesystem to the user, etc).
[1] - https://github.com/google/gvisor