Saving op files in /tmp/com.agilebits.op/.*

srcoder

There (session) information stored in the global scope of the filesystem /tmp/com.agilebits.op

I use per user home encryption and via this way after I logout this information is still possibly accessible for other users.
These dot (session) files also remain after I invoke op signout (--session= or via environment variable)

It would be better if you use ~/.local/tmp/com.agilebits.op for this which is in the user directory scope.

---

1Password Version: 0.1.1
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

srcoder

Changed version in original message to 0.1.1

cohix

Thanks for taking an interest in the tool :)

We chose the global scoped directory simply because those files are encrypted and entirely useless to anyone without the random key from op signin. We will however look into having the session files deleted on op signout. We currently clean up expired session files during the op signin command, but we can do better.

jpgoldberg

I haven't tested, but have you tried setting the TEMPDIR environment variable? I believe that op should respect that.

srcoder

Feedback first

@cohix totally happy to join the beta and providing some valuable(or in-valuable :smile:) feedback!
Already use it for some cases, still need to adapt to the jq -r lookup.

A quick note; op signin doesn't always remove old files from the /tmp directory(still can't tell why yet).
I could still read files from days ago, only the third successful login attempt or so few files were cleared.

@jpgoldberg TEMPDIR is ignored :cry: ... just tried via TEMPDIR=some/existing/tmp/dir && op signin someaccount (and export fails too)

More research

So, I don't agree on the given feedback, as the file itself isn't encrypted the json-data can be useful for any attacker.
IMHO not sharing is always better. I also do not have op installed globally, just locally for my user, so I can check the file isn't tampered.

The test.

I'm some other user, op is globally(because it's added via some trusted package manager) installed, I change it into a shell script controlling input and output(so read session-ids and change permissions of the written files in the global scope).
I think this is the most insecure part here, of coarse you are already screwed if this happens.

I do not need to information about the 1password account or host(central API), only need access to /tmp(miss configuration happens a lot :angry: , everything is 777 for instance). op --session=SES-S10N will give me full control over that session.

Also exporting as environment variable export OP_SESSION_test=SES-S10N needs me only tp create a file .op/config with `{"lastest_signin": "test"} to make it fully useful to me. This gives away more information about the lack of checks.

Lastly I changed all files /tmp/com.agilebits.op to 777 to and the sessions still could be used.

Out of scope

• test modifying the session files
• brute forcing session id's

Recommendations

• move to a user based files, or make it at least configurable
• check if the .op/config matches the session
• check if .op/device is correct
• check if the written file correctly written; has right permissions and belongs to the user
• check on read if the file still matches user and has the right permissions
• at least check more than just accepting the --session=
• something I missed

---

No ranting, just want to help you in this beta to turn it into a better product, also keep you guys sharp as a knife

rickfillion

TEMPDIR is ignored

Filed as issue #240

the [session] file itself isn't encrypted the json-data can be useful for any attacker.

What you're seeing is a JWK (json-web-key) message. It's a JSON structure describing encrypted data. It can't be tampered with without failing the authenticated decryption we do. Try tampering with it and see how far you get.

op --session=SES-S10N will give me full control over that session.

Assuming you got the session key from another user, yes. You need more than just access to the session file for that though. You would need the actual session key that was outputted by op signin. Where would you be getting that from?

Rick

srcoder

Rick, thanks for the heads up on the encryption in the json-data... (Al thought; Silence is golden...)

I replaced op in global scope with a script which also logs the SESSION variable somewhere else.
This is why I should suggest to never install op globally to make sure the original file isn't tampered with.

That's where my other suggestions came from to at least check if you own these files and if the permissions are correct.
Take a look at how ssh handles it's ~/.ssh directories. Try giving it to much permission and the keys won't be used to establish a connection.

rickfillion

Yeah, I do like how ssh treats ~/.ssh and I'd like us to mimic that eventually.

Rick

rickfillion

@srcoder : I was just looking to fix up the TEMPDIR thing, and it looks like Go's implementation of TempDir() looks for the TMPDIR environment variable and not TEMPDIR. Looks like TMPDIR is the correct environment variable for this. If you change your script to use that, I suspect it'll work as you'd expect. I've closed the 240 issue.

Rick

srcoder

Thanks for the heads up @rickfillion I'll start using that...
Will execute TMPDIR=~/.op/tmp ~/bin/op [COMMAND]

rickfillion

Sounds good. Let us know if that causes you issues.

Rick

srcoder

TMPDIR works without any problems. (sorry forgot to press Post :-p )

rickfillion

No worries. Thanks for the update.

Rick