[Opendnssec-develop] Again: Sharing PIN through POSIX message queues

[Rick van Rein]

Hello Rickard,

> Yes that would work if the processes behave. But I think it is
> possible for another bad process to attach to the same mailbox and
> then steal the message. You can "authenticate" the sender, but not
> "authenticate" the recipient.

Sorry if this comes in bits and pieces, but it's been two years...

The PIN requesting party would create a new queue for the response
with
	msgid = msgget (IPC_PRIVATE, S_IRUSR | S_IWUSR | S_IWGRP /*| S_IWOTH*/);

This creates a unique, internal message queue (see below) with
access privileges that permit owner+group (+others?) to send
and only the owner to read from the queue.  Note that this is
done by a "good guy" process; a rogue one would want to access
the msgqueue through other means.

You could send msgid as a data field to the PIN daemon's message
queu, to request sending the PIN to that message queue if the
sender's PID is acceptable.

Background:

| Syntax
| 
|  #include <sys/msg.h>
|  #include <sys/stat.h>
| 
|  int msgget(key_t key, int msgflg); 
...
| Parameters
| 
| key
|     (Input) Key associated with the message queue. A key of IPC_PRIVATE
|     (0x00000000) guarantees that a unique message queue is created. [...]

Ref: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fapis%2Fipcmsggt.htm

Then, from the Linux man page which is clear about privileges, it is
quite clear that other processes cannot receive from a properly
initialised message queue (see above) if they happened to find
the queue-id and tried to msgrcv() the PIN sent to it:

| When msgrcv() fails, errno will be set to one among the following values:
...
| EACCES
|     The calling process does not have read permission on the message queue,
|     and does not have the CAP_IPC_OWNER capability. 

What this means is that a rogue process could not share this channel,
as it would have to replicate the key; but given that the key is IPC_PRIVATE
the rogue process would simply be creating its own channel.

Of course, it is a good idea to restrict the queue over which the PIN
daemon receives messages so that only the PIN daemon can read from it.
It just shouldn't be IPC_PRIVATE because it _does_ have the intention
to be easy to find for others.

It would also be possible to protect the PIN requester against DoS
attacks by verifying that the last received message was sent by the
PIN daemon, based on the incoming pid_t.

> Does this mean that we get the same
> level of security as shared memory?

Certainly not -- we're now discussing the security of the response
channel, which should use the same mech for reasons of simplicity
only, but this approach definately raises an extra bar on which
PIN requests are acceptable.


Cheers,
 -Rick