Stub in more IPC attachment brokering functionality.

ipc/brokerable_attachment.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ipc/brokerable_attachment.h"
 
+#include "crypto/random.h"
+
 namespace IPC {
 
-BrokerableAttachment::BrokerableAttachment() {
+namespace {
+
+BrokerableAttachment::AttachmentId GetRandomId() {
+  BrokerableAttachment::AttachmentId id;
+  crypto::RandBytes(id.nonce, BrokerableAttachment::kNonceSize);

[agl, 2015/06/24 00:59:56]

What are the security requirements around this? You've increased the nonce size
from 4 to 16 bytes. Is a global counter unsuitable?

The use of crypto::RandBytes suggests that there's some security property here
but that's unclear. If not, then base/rand_util.h should suffice.

[erikchen, 2015/06/24 01:06:02]

The nonce used to be 4 uint32_ts, now it's 16 uint8_ts, so there no change in
total size. The security requirement is that the nonce should be unguessable,
and there should be no nonce collisions. Based on the number of expected IPC
messages and the birthday paradox, 16 bytes seemed like the right size.

(This information is also available on my design doc:
https://docs.google.com/document/d/10OiW_YGxQsiTLaP1x3Yp0ymIEEJEBKqFPMVlFDdFZ...
)

[agl, 2015/06/24 01:28:57]

Ok. Please comment:

// In order to prevent mutually untrusted processes from stealing resources from
one another, the nonce must be secret. This generates a 128-bit,
cryptographicaly-strong random number.

[erikchen, 2015/06/24 17:50:25]

Done.

+  return id;
+}
+
+}  // namespace
+
+BrokerableAttachment::BrokerableAttachment() : id_(GetRandomId()) {
 }
 
 BrokerableAttachment::~BrokerableAttachment() {
 }
 
 BrokerableAttachment::AttachmentId BrokerableAttachment::GetIdentifier() const {
   return id_;
 }
 
+BrokerableAttachment::Type BrokerableAttachment::GetType() const {
+  return TYPE_BROKERABLE_ATTACHMENT;
+}
+
 }  // namespace IPC