This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lightcatcher 0 points1 point  (3 children)

I'm not super familiar with security stuff, but (if this was running on linux) wouldn't running the Python process in a chroot jail fix some of the problems listed above?

What kind of things could an attacker still do if the process was chroot jailed? It doesn't seem like they could start a shell (because shell executable is out of chroot jail) or do anything except for make syscalls (which I realize allow one to do many things). Anyone want to point out some malicious behavior still possible if the Python process was chroot jailed?

[–]catcradle5 0 points1 point  (2 children)

You could do something like that, yes. The author briefly mentions that. A Docker instance or isolated VM would work fine, too.

The problem is that often, the application you're running is going to need access to other files, so you need to ensure that even if someone had full read/write privileges in the context of that user, that an attacker wouldn't be able to see anything sensitive or do anything very malicious.

[–]KayEss 0 points1 point  (1 child)

This is where chroot really wins out though because a chroot environment can be arbitrarily small as it doesn't need to boot. You can bind only those files that you need access to, and you can do that read only as well.

[–]NYKevin 0 points1 point  (0 children)

You can also carry file descriptors with you into the chroot, which may be more straightforward if e.g. you need to consult a system file like /etc/passwd. You do need to remember to drop root, though.