the cleartext password issue

[john heasley]

Sat, Jan 12, 2002 at 01:05:50PM -0800, Avram Dorfman:
> Hello Everyone,
> 
> I've dealt with rancid-style packages for a while that I home-grew, before rancid came along, so I've faced this annoying clear-text password in a file issue many times before.
> 
> One way that I've considered handling it (although never actually implemented) is this: 
> 
> Encrypt the password file, but rather than storing that key in a file, have a "daemon" process that you have to launch manually, which prompts for it. Then this process would simply keep it in memory, and be responsible for doing all the sensitive stuff. 
> 
> I never implemented it for two reasons: 1) I couldn't think of a way to still get the scheduling benefits of cron, while having this process be the one that does everything, and 2) if someone hacks into the rancid user's account after an operator has manually launched the daemon, he could still subvert the process by mucking with the config files to direct rancid to login to a trojan horse, and steel the password there. Thus, the limiting factor is still the ability to become the rancid user.
> 
> But I thought I'd throw it out there in case anyone else can expand on it for a real solution.
> 
> -Avram

this is the 2nd largest cost of automation and i have not been able to
come up with a viable solution.  if you have a daemon and someone hacks
root or an account in group kmem, it is possible to look through memory
and extract the password.  or that daemon dumps a core in some world
readable area ... and so on.

protecting the rancid users' area and .cloginrc along with the unix box
itself are the best methods.

we still would like to add something like {<user>} as a possible password
token which would cause *login to prompt the user.  allowing a .cloginrc
to be shared among many users, but which contains no actual passwords.
which would also be helpful for secure_id logins.

it would be nice if all vendors did AAA and had a priv level that could
look at everything, but not modify.  then rancid would not need write
privs.  i believe this is possible on juniper with a local user definition
and may be possible with AAA via radius.  of course, the user making
automated config changes still has privs ...