[OTR-dev] private messages on dbus

[Dimitris Glynos]

On 02/28/2012 01:09 AM, Howard Chu wrote:
> Dimitris Glynos wrote:
>> On 02/28/2012 12:43 AM, Paul Wouters wrote:
>>> I am still a bit confused how serious this issue really is. If you can
>>> read as the uid of the user, you can already read the OTR keys from
>>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus
>>> or the X11 channels doesnt really matter much. So I see value in
>>> protecting the pidgin process from reading OTR materials outside
>>> pidgin-otr, and hardening pidgin against network input, I see less value
>>> into closing the dbus from the user for themselves.
>>
>> Paul the real problem here is broadcasting sensitive info
>> over DBUS. If the sender chooses not to log this info
>> so that they don't end up on the disk, there is no way
>> for pidgin to enforce the same security policy to the
>> 3rd party (possibly unrelated) apps that sit on the
>> other end of DBUS. Such an app might accidentally log these
>> messages because it cannot qualify that they were meant to be
>> private.
> 
> That sounds like a bug in the 3rd party code then, since pidgin marks
> its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged,
> and the otr plugin will turn off conversation logging if the user
> chooses that.

Well, actually it doesn't do that :-)

I have logging disabled, but as you can see below the other
end of DBUS only sees PURPLE_MESSAGE_SEND / PURPLE_MESSAGE_RECV
switched on.

signal sender=:1.11 -> dest=(null destination)
path=/im/pidgin/purple/PurpleObject;
interface=im.pidgin.purple.PurpleInterface; member=WroteImMsg
   int32 66666
   string "anonymized at example.com"
   string "this is a test"
   int32 77777
   uint32 1 <------------- PURPLE_MESSAGE_SEND
...
signal sender=:1.11 -> dest=(null destination)
path=/im/pidgin/purple/PurpleObject;
interface=im.pidgin.purple.PurpleInterface; member=ReceivedImMsg
   int32 66666
   string "anonymized at example.com"
   string "ok"
   int32  77777
   uint32 2 <------------- PURPLE_MESSAGE_RECV

And I mentioned logging only as an example. There is no way to make
sure that the 3rd party apps on the other end of DBUS adhere
to the same security policies enforced by the sender.

So, a suggestion is to create a new type for private messages.
By default private messages should not be broadcasted over DBUS
or be logged. Users will have the option of changing this
if they want to.

Regards,

Dimitris