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

Support multiple accounts, possibly allow PAM for authentication/authorization #167

Open
asegu opened this issue Aug 30, 2017 · 3 comments

Comments

@asegu
Copy link

asegu commented Aug 30, 2017

Currently I'm using GoTTY in combination with login on a linux box to have the equivalent of SSH to the box via the browser. The following is an idea that came out of my use case.

An administrator running GoTTY would like to use GoTTY with multiple users allowed to work with the server at the same time, without using a shared username/password.

Implementation ideas:

It could be done via PAM or via a separate credentials DB, or even just specifying multiple credentials in the configuration.

The advantages I see with PAM are:

  • GoTTY could use any authentication backend that PAM supports if based on username and password (ex: LDAP, some RADIUS/EAP methods, etc) for extra flexibility.
  • The process started by GoTTY could optionally be run as the user that has logged in (ie: similar as if using sudo gotty login, the resulting shell is running as the user logged in -- requires running GoTTY as root however)

The admin would likely want to specify which service GoTTY represents itself as towards PAM, allowing the user to login as if they had connected via ssh, sitting at a console, or based on its own profile and authentication sources.

@yudai
Copy link
Owner

yudai commented Aug 31, 2017

Thanks for the request.

I think your proposal has two separate topics.

  1. Authentication to access Gotty process using PAM
  2. Setting uid/pid to child processes

As for 2, I think we can simply use sudo and this is the most safer and simpler way. For example you can write a script like below:

!/bin/bash

user= #Need some info from auth

exec sudo su -u ${user} login

(You may want to create a user for the gotty process with proper sudors config to disable password confirmation)

However, as mentioned in the comment above, we currently do not have the user name used by the authentication in this context. So probably we can add an environment variable like GOTTY_AUTH_USER and make gotty set it when authentication success.

For 1, I actually have some use cases that need integration with an external authentication system such as SAML. (We have a PR that adds SAML support ) I'm now wondering what interface is the best for this purpose. PAM can be a candidate as well?

@yudai
Copy link
Owner

yudai commented Aug 31, 2017

I realized that #166 has an option for

So probably we can add an environment variable like GOTTY_AUTH_USER and make gotty set it when authentication success.

@asegu
Copy link
Author

asegu commented Sep 1, 2017

Hi,

Your split between the topics is fair.

Regarding 1 / PAM, I do believe this would give GoTTY a lot of flexibility. Does it solve SAML as well? Not a use case particularly interesting for me at the moment, but a quick search does bring up mentions of a few PAM modules doing SAML. Unfortunately nothing seems to have a large following, so I can't fully judge if this feature request / PAM would cover that as well.

Regarding 2 / setting the UID/PID, I'm thinking about this in relation to your comment to the pull request I made (#166) and the advantages/disadvantages of scripts used to start a shell. In my mind, two factors come to play - usability and security, I consider that having setuid as an option in GoTTY would be somewhat better than special sudo configuration + scripts:

  • Usability: having only the GoTTY binary and a command line like 'sudo gotty --auth... --setuid bash {args from url}' would be almost equivalent to 'gotty --auth... <script to set uid>', but would require only one file (the binary) and no additional scripting / configuration.

  • Security: 'sudo gotty' implies there's a program as root open to the network, and any bug leading to remote code execution would lead to a pretty bad situation. But does running 'gotty sudo' add any real security to the feature? Remote code execution could then simply try launching sudo anyways.

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

No branches or pull requests

2 participants