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

tensorboard with unshare #2

Open
johrstrom opened this issue Feb 4, 2020 · 1 comment
Open

tensorboard with unshare #2

johrstrom opened this issue Feb 4, 2020 · 1 comment

Comments

@johrstrom
Copy link

Hi! We've looked at your proxy for tensorboard and it's quite nice (just a single file to deploy, no muss no fuss, etc). But tensorboard is still reachable if one knew the port.

I've got a branch here that uses unshare to create a new network namespace so that tensorboard can boot in it and stay unreachable. Of course this relies on the users ability to use unshare (they need access to subuids) which isn't enabled in most systems.

This ticket is just to let you know of that work, and that we've modified your authrevproxy (and copied your license and noted these facts in the README). The modifications were mostly just updates to use python3, twisted 19 and enable being run by root.

Let me know if the licensing in that branch is what you'd expect (or if you want me to cease and desist and remove it entirely. as it's GPL I'm happy to push whatever updates you'd like back here).

@kcgthb
Copy link
Member

kcgthb commented Feb 4, 2020

@johrstrom Thank you very for letting us know about your improvement!

It's true that although the tensorboard process is bound to the local 127.0.0.1 address and can't be access from another host, any process running on the same node could still bypass the authenticating proxy and access the Tensorboard interface directly, unauthenticated. Using unshare to avoid that issue sounds like a good idea when it's available.

Maybe a further improvement would be to try to detect if users can run unshare and if the required tools are available in the current environment , and if not, fall back to the previous behavior? That way, this security measure could be implemented if the host setup allows for it, but the app would still work when unshare can't be used?

No problem for the license, it's perfect as it is, and thanks for crediting us!

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

2 participants