To move things along and continue the discussion on SSH and the integration policies. "Should they run as the same user?"
The client does allow people to access other software residing in other computers running the ebrainpool client. This brings in an interesting view point. What about security? Does the remote user have any access to the information and structures resident on the local machine?
Current scene: The current system we use is to launch the client as the same user who has logged in. We use openssh present in the system, but with our own shipped custom config files, since we felt it necessary to ensure at least a basic level of security. Of course though, this can be changed quite simply from the code, or by editing the shipped config files for ssh server and ssh client.
Thoughts we have:
-
Ideally perhaps the client should be run as a separate, sandboxed user, this is an area we have contemplated, not implemented in the current proof-of-concept code. This does have the added advantage of being pro-security and isolated, but might detract from intended functionality. Is it over-kill ?
-
keep it as the same user, the user has complete control of whom to allow and whom to decline anyway. The drawback here, is that the users might not fully understand the security implications of allowing people access. We intended on locking things down (like FS access etc., FUSE plays a big role here) and isolating as much as possible.
- Keep the ebrainpool client as the same user, but run ssh as a sandboxed user. I actually just thought of this one, so it might sound odd, even to me when I read this in the morning. Additionally, considering our new direction involving libssh integration, accomplishing this might prove troublesome. The more I think about this, the more I think I like it. Accomplishing this might prove another story and remains to be seen if it is actually worth it.
Anyway, thats all for now, will follow up with more discssions on these, as always feel free to jump in with your thoughts.