Using securely on a shared machine

[awick]

Is it possible to use the cli securely on a shared linux host? My thought is probably not, but trying to figure out what risk level would be acceptable.

Seems like not using the agent or setting a tiny timeout plus removing the blob on logout would be one step in the right direction.

I do wish there as a --filter option on login that would allow me to somehow filter which keys could be retrieved during that session.

Sorry if I missed some docs or obviously ways on how to do this.

[bcopeland]

It depends on your security model. If you want to protect yourself against other normal users, then you can probably just run it as-is: the agent socket is restricted to current user id, so this is roughly the same as preventing other users from reading your files (that is, standard unix permissions apply). If you want to protect yourself from root, best not to use it at all on that machine.

[awick]

Ok thats what I figured.

Thoughts about making a lpass login --filter type option? So for example I could say something like "lpass login --filter tacacs" and then on that box only the tacacs password could only ever be retrieved? So then root could only get my tacacs password, which they could already reset, but they couldn't get to other datas.

[awick]

Just the further clarify the use case. We are using ansible from a shared admin host, and hoping to put things like our tacacs passwords and shared ansible vault passwords into lastpass and using lpass show --password in the automation so we never have to know them, just our last pass password. For boring reasons we can't use ansible from our laptops or just ssh proxy thru the jump hosts. Since we are using lastpass enterprise many have linked their personal accounts, so would rather root couldn't see that, and even better if we could limit it to a few keys.

[bcopeland]

--filter doesn't really make sense from an architecture standpoint: the master password is enough to decrypt the whole vault and the agent doesn't store or hand out individual site passwords anyway, it just hands out the key to the main blob to the client. The linked personal account keys are stored in the blob.

You could, I suppose, make a version of lpass that discards sharing keys from the vault when downloading so that linked personal accounts do not appear in the blobs, but anyone determined could just snag the keys and use the normal client to retrieve them. Root can always dump memory, replace the lpass binary with a trojan, etc., so hiding from root is a losing proposition.

What I would do in your situation (licenses permitting) is make a new lastpass enterprise account for the automation stuff, and add that user to a shared folder that everyone else is in. Then, that account would not have access to any personal accounts but you could still put new accounts or edit accounts on behalf of the automation user.

[awick]

Ok thanks, definitely clarified things. We can't use a single automation account since each user has a unique tacacs password, but a shared ansible vault password. So everyone would need a second account. Anyway, I think our answer is fixed why we want to use a shared machine, and make it so we use the shared host as a jump proxy.