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

Encrypting Chromium passwords? #22

Closed
IridiumMaster opened this issue May 23, 2017 · 4 comments
Closed

Encrypting Chromium passwords? #22

IridiumMaster opened this issue May 23, 2017 · 4 comments

Comments

@IridiumMaster
Copy link

IridiumMaster commented May 23, 2017

Hi there,
I'd like to make sure that Chromium saved passwords are not visible in the VNC in a state I've saved. I'm using your Centos/XFCE distribution. The way to do this appears to be to install gnome-keyring and administer it with seahorse, thus making it the password provider for Chromium. I've added both utilities, but neither they (nor I) can understand what you've done with the "default" login (uid 1984). I can't set a password for this login (passwd tells me "cannot identify you"). Adding users results in password-less users being created... very confusing. Could you please indicate how to:
Enable a login-free desktop that nonetheless has an implicit password for a user that triggers the gnome keyring to function properly? Thank you so much in advance for your help.

@toschneck
Copy link
Contributor

Hi,
the original purpose of this image is that it will be used only for short term actions. In our case to execute E2E tests in real browser. Because of that, the image is designed more or less stateless. If you wan't to used like a VM with states and userpassword and so you can extend the base image by your own like described here: https://github.com/ConSol/docker-headless-vnc-container#1-extend-a-image-with-your-own-software

If you want e.g. use the user id 1000 you can do:

## Custom Dockerfile
FROM consol/centos-xfce-vnc:1.1.0
USER 1000

### do your stuff

In our case we use the "nss_wrapper" library to fill passwd at runtime. Which is recommended by Redhat https://docs.openshift.com/enterprise/3.1/creating_images/guidelines.html#openshift-enterprise-specific-guidelines.

One thing you have to know, that we currently don't launch an DBus, so I'm not sure if the keyring than works.

The Linux users itself don't have any password, to the only password we set is the VNC password. The current implementation needs to set a password as environment var VNC_PW. Do you really wan't to be able to set no VNC password, and everybody how listen to your VNC port can access your data? I could change the startup script, that it allows a empty VNC password, but I'm not sure if this is needed and reasonable. For noVNC connection you can provide the password as parameter and ensure, that you don't have to login, e.g.:
http://localhost:6911/vnc_auto.html?password=vncpassword

@IridiumMaster
Copy link
Author

Hi there,
thank you so much for your reply. I will be parsing through the material you have provided this weekend. I am a bit confused by your last paragraph. Perhaps explaining my setup a bit more will help clarify.

  1. I manage access to virtual environments through an SSH-tunnel on the desktop that is generated by a Java program I wrote. This tunnel must be setup for anyone to be able to reach the no vnc / vnc ports. Thus, no one is going to be snooping on the vnc port because no one can see it or connect to it without already being authenticated via standard Linux SSH mechanisms.
  2. I do, as you mention, auto-fill in the URL with the VNC password, so connecting is as simple as clicking "connect." I appreciate that the VNC password is there, because I auto-randomize it as a way of preventing clients from accidentally stepping into each other's sessions.
  3. I provide convenience facilities to my users that cache certain Chrome passwords. Originally, it was alright to have these Chrome passwords accessible to everyone. But as work has been subcontracted, the users have a need to hide the Chrome passwords from others so they do not use these passwords outside of the virtual environment.
    I have a couple of alternatives that I am exploring with regard to Gnome-Keyring alternatives:
  4. Firefox with a master password. As you are aware, the latest version of Firefox suffered from poor performance and graphical distortion that rendered it unusable in the Ubuntu version of this image. In the Centos version, I have gotten it to work alright, but my last experience did not inspire confidence and Firefox doesn't accept all the plugins my users need.
  5. https://github.com/dannyvankooten/browserpass
    I am in the process of installing this. Unfortunately, it already appears that in a password-less environment, the password can be retrieved by simply typing "pass" + the name of the website in a terminal. If there were a password associated with the docker image, I could lock access down accordingly.
    In any case, as I mentioned, I haven't had a chance to review what you've provided. I will do so and provide my experience and feedback. I greatly appreciate the work you've done on this image.

@toschneck
Copy link
Contributor

Hi, thx for your detailed explanation. Hope you will get this working.
To your 5th point: Maybe you can use for that a keepass file in connection with keepass http plugin. Therefore you can unlock the keepassfile on startup and provide it with auto-fill-in over the keepass browser plugins. I think this won't be some easy task, but I just wanted to mention it 😄

@toschneck
Copy link
Contributor

@IridiumMaster can I close the Issue? Maybe you can post here your solution?

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