gpg-agent isn't quit upon logout
Why is gpg-agent still running even after I logout of my Mac's user account?
I don't like the idea that my user's gpg-agent is still up and running, presumably with passwords cached, when I'm logged out. Can't anyone who can change my user account password (like ANY other user on the machine who's an "Administrator" according to OSX) open my allegedly secure files while I'm logged out because my gpg-agent is still running? Suppose I have "foo.gpg" and I decrypt it to stdout. Say I've configured my gpg-agent to have a timeout of 10 minutes. Now I logout. Gpg-agent is still running! All they would have to do is change my Mac user account password, then see my allgedly secure file "foo.gpg" by doing the following: su myusername (since now they know my user pw), then gpg -d foo.gpg. Won't my gpg-agent then give them access to my document (so long as the timeout hasn't happened yet)?
This seems like a huge bug to me. And it seems like a bug EVEN if the method I described above wouldn't work. The agent should die when the user logs out.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Rasputin on 19 Mar, 2012 11:10 PM
Hey... Cool. This was my next question.
Support Staff 2 Posted by Luke Le on 20 Mar, 2012 12:16 AM
Hi C,
we understand your concern but the problem is a bit more complicated.
Actually the problem starts with physical access to the machine or even remote access to it.
Let's assume someone with an admin would indeed have access to your machine they could just as easily install a key logger which would record your password the next time you enter it.
We could kill the gpg-agent at logout but it wouldn't help that cause.
If someone were to login to your computer from remote again, while you're running a session, they could again simply use a sudo command and possibly access the gpg-agent cache to decrypt your file.
So, it's true, we could add a logout hook to OS X which killed gpg-agent instances, but it wouldn't help security much.
The best way to go, if you're files are that sensitive, is setting the cache time of gpg-agent to 0 and keep your .gnupg folder on a data-stick.
3 Posted by Rasputin on 20 Mar, 2012 12:46 AM
I think this is - "we have do ALL what we can do for your security - the tag is your job" - matter.
Simply duty-exercise without ifs, ands or buts :-)
4 Posted by C. Diza on 20 Mar, 2012 02:40 PM
OK. I still think it should be built into GPGtools, but never mind.
I've created a workaround that I'd like to share in this discussion, followed by a question to the support staff.
The Workaround: create a LogoutHook that calls a shell script that stops the agent. Create a script like this:
In Apple's (deprecated) hooks, $1 points to whoever the user who initiated the Login/out is. We need that part lest it be the case that "anybody's logout kills everybody's gpg-agent". Store that script wherever you want, and do:
sudo defaults write com.apple.loginwindow LogoutHook "/users/myusername/scriptlocation/script.sh"
Now whenever anyone logs out, their agent goes away.
My question for the support staff is: is using killall a safe way to stop the agent? Or does that wind up leaving cache files laying around? Is there a better command to use?
Support Staff 5 Posted by Luke Le on 20 Mar, 2012 02:59 PM
The workaround we've discussed looks exactly the same, so yes, this works.
6 Posted by cfraire on 23 Mar, 2012 08:39 PM
I suddenly started seeing gpg-agent running for some of my process daemon users (e.g., rabbitmq). Examining org.gpgtools.macgpg2.gpg-agent.plist in /Library/LaunchAgents/, I was confused to see LimitLoadToSessionType set to Background when I would have sworn it had been set to Aqua.
Now I've learned that the MacGPG2 installer writes a org.gpgtools.macgpg2.gpg-agent.plist with LimitLoadToSessionType set to Background, and it is gpgtools-autofix.sh fixMacGPG2 which has been re-setting this to Aqua in order to allow keychain support in Lion.
With LimitLoadToSessionType set to Aqua, my gpg-agent seems to be terminated when I logout.
Support Staff 7 Posted by Steve on 04 Apr, 2012 07:24 PM
Ok, looks like we have a nice workaround for this problem.
This issue won't exist in MacGPG2 2.0.19 because 2.0.19 won't use the launch agent.
So closing this discussion.
@Diza: Please open a new discussion should you have more questions or re-open this one here, if you have sth you'd like to add...
All the best :)
steve
Steve closed this discussion on 04 Apr, 2012 07:24 PM.
C. Diza re-opened this discussion on 09 Apr, 2012 04:48 PM
8 Posted by C. Diza on 09 Apr, 2012 04:48 PM
@Steve: Uh, I'm confused. I'm using 2.0.18 and there is no launch-agent being used. When I installed 2.0.18 it removed the launch-agent that used to be there and didn't replace it with anything; and yet I was still having the issue of gpg-agent not dying at logout. In fact, it was my noticing that gpg-agent STILL wouldn't die even after the launch-agent was removed that made me irritated enough to start this thread.
So I don't think the issue is solved by the absence of launch-agents.
Support Staff 9 Posted by Luke Le on 09 Apr, 2012 05:54 PM
Hi c,
it's true this issue isn't resolved since we don't
necessarily consider it an issue, based upon the points outlined
in one of my previous posts.
2.0.19 does away with the launch agent since gpg starts
gpg-agent on demand.
You're best option is still the logout hook.
10 Posted by C. Diza on 12 Apr, 2012 04:09 PM
The reason I was confused is that Steve seemed to suggest that there would no longer be a need for my logouthook workaround once 2.0.19 comes out, for the reason that 2.0.19 does away with the launchagent.
This confused me because 2.0.18 already did away with the launchagent (at least it did on my machines), and yet I still need the logouthook.
By "I don't think the issue is solved by the absence of launch-agents", I simply meant "the absence of a launchagent does not mean I no longer need the logouthook"---the latter is what I thought Steve was saying...but I was wrong :)
Support Staff 11 Posted by Steve on 12 Apr, 2012 05:19 PM
Diza, to be honest: It was a misunderstanding on my side. You are perfectly right about this.
Steve closed this discussion on 12 Apr, 2012 05:19 PM.