permissions required on /run/user/<uid>/gnupg

[Daniel Kahn Gillmor]

On Wed 2016-10-05 13:22:11 -0400, Werner Koch wrote:
> On Wed,  5 Oct 2016 17:34, dkg at fifthhorseman.net said:
>
>> I've noticed that the permissions set on /run/user/<uid>/gnupg have an
>> effect on the choice of standard socket.
>
> I implemented it this way to cope with the case that other software
> already used a directory under this name and does not guarantee the same
> permissions GnuPG needs.  I know, this is highly unlikely but after all
> this socket allows access to the private keys.

is the concern here about "hijacking" like what gpg-agent did?

> Thus better fallback to the old standard name if something smelss
> fishy.

sorry, i don't understand whether you mean this about the decisions made
during socket creation/listening (gpg-agent's perspective) or socket
connection (gpg's perspective).  Writing the e-mail earlier made me
realize that these are really two distinct sets of choices and despite
wanting to reuse code where possible, i think we might need to make the
two decisions differently.

>> Is this restriction the right choice?  The rationale for it from
>> gpg-agent's side is presumably that you don't want to expose the socket
>> to other users on the machine.  And from gpg's side, of course, it wants
>
> These are the same restrictions we have for ~/.gnupg .  Thus the move to
> /run/user didn't changed anything regarding permissions.

so if the permissions on ~/.gnupg are too loose, the agent won't listen
on a socket there -- is that right?

>> But consider the use case of an isolated agent, run by one user account
>> and deliberately exposed (on the same machine) to another user account.
>> In that case, the permissions shouldn't be so strict.
>
> I think it would be okay to relax the permissions to allow group RW for
> the socket file.  I am not sure about the directory.

For Linux, i believe that permissions on sockets are meaningful.  iirc,
there are other unix-es that ignore permissions on unix-domain sockets,
so the directory permissions are the most important.

>>    a) if /run/user/<uid>/gnupg is owned by me and mode 0700, then listen
>>       on S.gpg-agent in that directory.
>>    b) If not, then listen on ~/.gnupg/S.gpg-agent
>
> I fact, would like to entirely get rid of sockets in the homedir.  We
> still need them for compatibility reasons but in the long term they
> should go away.

I'd love for them to go away as well!  how should we cope with
non-standard homedirs, though?  I'm thinking about test suites, or
projects that want to use gpg with an isolated set of keys.

> The logic you propose makes things even more complicate than they are
> right now.
>
> Shouldn't we discuss this based on a concrete proposal? 

well, i tried to make a concrete proposal, though i grant that it's more
complicated than the current situation :)

> For isolating gpg-agent and gpg, what about using a separate
> sub-directory with permissions suitable for this?

if the parent directory is mode 0700, then any subdirectory won't be
accessible to a different user, right?

>> Alternately, is there a way to explicitly instruct gpg (and other
>> clients of gpg-agent) to use a specific socket somewhere else?  We've
>
> I have seen such a feature request / bug report.

could you point me to it?  I'd like to follow up on
https://0xacab.org/monkeysphere/monkeysign/issues/9#note_10491

> Before we do a quick hack here, we should evaluate the use case in
> more detail before we come up with a solution.

There are several different use cases for clients of gpg-agent to use a
distinct agent.  Where would you like me to document them?

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161005/9aa44928/attachment.sig>