-
Notifications
You must be signed in to change notification settings - Fork 26
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
Access limitations for bots #33
Comments
Up until now I've been reliant on user permissions and running as an untrusted user. I'm not sure if theres a good way of doing this programatically, but I might take a look into this when I get time |
Basically you would need to implement some form of Sandbox. I think this should be offloaded to the underlying host system. (chrooted env/user accounts) |
Unfortunately, it is easy to jump out of chroot. Probably we need a set of restricted users or groups. |
This is true, (chroot is not a security feature) but at least another step to take for an attacker. Restricted Users should be used in any case. Ill eval some possibilities. (firejail,selinux,containers) |
I can add 'run under userX' to UnixTools however I need to know the userX's user id and group id. |
The bots should only have access to the working directory (and sub-directories). It is especially important that they can not interrupt the other bots processes.
The text was updated successfully, but these errors were encountered: