Pinentry makes it awfully easy to snoop all passwords entered by the user

[Niklas Schnelle]

Just found this discussion about the same problem in ssh [1]. I do realize
that the root user accessing
this info is not really a problem it's trusted anyway and can do much worse
including just reading your process memory.
However it would be nice to have a way to disable tracing for normal users,
I mean there isn't really any reason another process should be able to
watch your processes system calls just like there are facilities to keep
the kernel from swapping certain RAM areas. Maybe we should bring this up
in the kernel community things like AppAmor and SELinux already reduce what
processes can do, somehow I feel like this should be a special capability.
This is actually quite a good reason for why Android in general has a
better security model for today's day and age than normal desktop Linux,
there every process runs as a different user. I think the kernel folks even
limited access to some /proc files for exactly the same reason.

[1] https://plus.google.com/107770072576338242009/posts/ETqpKHLUEKr


On Wed, Aug 28, 2013 at 8:40 PM, Niklas Schnelle
<niklas.schnelle at gmail.com>wrote:

> Just found this discussion about the same problem in ssh [1]. I do realize
> that the root user accessing
> this info is not really a problem it's trusted anyway and can do much
> worse including just reading your process memory.
> However it would be nice to have a way to disable tracing for normal
> users, I mean there isn't really any reason another process should be able
> to watch your processes system calls just like there are facilities to keep
> the kernel from swapping certain RAM areas. Maybe we should bring this up
> in the kernel community things like AppAmor and SELinux already reduce what
> processes can do, somehow I feel like this should be a special capability.
> This is actually quite a good reason for why Android in general has a
> better security model for today's day and age than normal desktop Linux,
> there every process runs as a different user. I think the kernel folks even
> limited access to some /proc files for exactly the same reason.
>
> [1] https://plus.google.com/107770072576338242009/posts/ETqpKHLUEKr
>
>
> On Wed, Aug 28, 2013 at 8:12 PM, Daniel Kahn Gillmor <
> dkg at fifthhorseman.net> wrote:
>
>> On 08/28/2013 11:39 AM, Niklas Schnelle wrote:
>>
>> > So as I understand it pinentry is used to request a password from the
>> user
>> > and it then sends that password to the requesting process via a pipe.
>> The
>> > problem here is that this
>> > makes it a lot easier to snoop passwords than if gnupg read them in a
>> more
>> > direct way.
>>
>> Surely the same systemcall tracing approach could be tuned to scrape the
>> passphrases from direct tty input as well?
>>
>> If i understand it correctly, in newer versions of gpg (2.1, not yet
>> released afaik), the agent is designed to not transmit passwords to gpg
>> itself at all; instead, the agent hangs on to the keys and only
>> asymmetric crypto challenges and responses are communicated between the
>> agent and the gpg process.  So if you're really only concerned about
>> what's passing across the pipes then you probably want to move to the
>> newer version of gpg and test that out.
>>
>> but basically: if your adversary has root on your machine or has full
>> control over your local account even, there isn't a way to use gpg (or
>> any software) safely.  This is unfortunate, but it seems to be the way
>> things work. :(
>>
>> Regards,
>>
>>         --dkg
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130828/4a300b8a/attachment.html>