Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

I'm working on a VM in a university environment, where several other users also have root access. Take a config file like /etc/rhsm/rhsm.conf:

proxy_hostname =
proxy_port =
proxy_user =
proxy_password =

Now the university's proxy server requires a username and password. But I really don't want to store my own personal username and password in a file that other (trustworthy as they may be) sysadmins can and will read. Is there a solution?

In the case of Git, we're able to each have our passwords in our local directories. (Come to think of it, this technically isn't secure as anyone can read any directory, but at least other sysadmins won't accidentally bump into the password without looking for it.)

share|improve this question
One potential solution that comes to mind would be to run a local (passwordless) proxy that relays to the real proxy. Are there others? – Steve Bennett Oct 25 '11 at 23:47
3  
The real issue is why there are so many people with full root access whom you seem to have little trust in. everywhere I've worked as a sysadmin, we always found ways to use permissions/ownership/groups and if need be sudo to provide junior admins with all necessary access without ever having root (or using it, even if you had it). It prevents your very dilemma - I'm unsure there's a way to prevent others from seeing the contents of the file. Perhaps redhat will let you enter an encrypted pass string? – sandroid Oct 26 '11 at 1:06
It's not "so many people" - maybe 3. And there's a difference (from a social perspective) between a password stored somewhere that a determined wrongdoer could find, or one stored write there in your face in a config file. I'm pretty sure these other sysadmins would not actively look for my password in my home directory. But it would be wrong to leave it lying around in a shared config file. – Steve Bennett Oct 26 '11 at 2:12
In this case I would recommend the first option that I suggested in my post. However I would check whether this is in compliance with Password and/or security policy at your university. Either include other file if it is possible for rshm.conf or use other local proxy. – Radek Hladík Oct 26 '11 at 11:34

1 Answer

up vote 2 down vote

Plain answer it is not possible. The root user has complete access to the server. There are tools like SELinux that could make it harder for other admins but not impossible.

Basically there are three options:

  • obfuscate it a little by hiding the password somewhere in your directory. I.e. run your own proxy with configuration in ~/boring/work/stuff/completely/unrelated/to/proxy/password.cfg as Steve suggested. Or convince the proxy to ask a program to get the password (or the config file) from some binary that will try to check whether it is sending the password to the proxy process. Or compile the proxy binary with password hardcoded. There are many possibilites but all are security through obscurity.
  • Store the password somewhere where you are the only admin or you are the only owner (some other server, flashdrive, etc..) and try to convice the proxy to get the password somehow from that location.
  • Ask for a different password that would not need to be protected against other admins.

First option would be good if you "trust" the oter admins and you just want to protect the password against accidental stuff. The second one would be the "correct secure" way. And the third one would be "correct enterprise" way.

But there is another thing that you should think of. Once the password is loaded into the proxy, bad guy can try to get it out of the proxy. As this may seem to be not so big issue, if the authentication process to the parent proxy uses passwords in plaintext, it may be very easy. And even it could happen as accident by some of the other admins analyzing the network traffic for a valid reason.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.