Don't upload extension IDs in the cloud policy protocol.

chrome/browser/policy/test/policy_testserver.py

 # Copyright (c) 2012 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.
 
 """A bare-bones test server for testing cloud policy support.
 
 This implements a simple cloud policy test server that can be used to test
 chrome's device management service client. The policy information is read from
 the file named device_management in the server's data directory. It contains
 enforced and recommended policies for the device and user scope, and a list
@@ skipping 39 matching lines @@
   "robot_api_auth_code": "fake_auth_code",
   "invalidation_source": 1025,
   "invalidation_name": "UENUPOL"
 }
 
 """
 
 import base64
 import BaseHTTPServer
 import cgi
+import glob
 import google.protobuf.text_format
 import hashlib
 import logging
 import os
 import random
 import re
 import sys
 import time
 import tlslite
 import tlslite.api
@@ skipping 386 matching lines @@
               'google/ios/user')):
         if request_type != 'policy':
           fetch_response.error_code = 400
           fetch_response.error_message = 'Invalid request type'
         else:
           self.ProcessCloudPolicy(request, token_info, fetch_response)
       else:
         fetch_response.error_code = 400
         fetch_response.error_message = 'Invalid policy_type'
 
+    # Send additional PolicyFetchResponses for each extension that has
+    # configuration data, if the main request had a single user policy request.
+    if (len(msg.policy_request.request) == 1 and
+        msg.policy_request.request[0].policy_type in ('google/chromeos/user',
+                                                      'google/chrome/user')):

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

Wouldn't the correct implementation be to check whether *any* of the incoming
requests was for user policy?

[Joao da Silva, 2014/04/24 13:22:24]

I'm not sure. Since we don't send PolicyFetchRequests for extension policy, we
use the signing parameters from the user PolicyFetchRequest. If there is more
than one then which one triggers the fetch of policy for extensions?

Alternatively, we could do this for each user PolicyFetchRequest. In that case
the order of the responses will be significant.

I'd rather not make any assumptions about that at this stage, since we're still
in a simple world where there's 1 user PolicyFetchRequest per request :-)

[Mattias Nissler (ping if slow), 2014/04/24 13:38:25]

IIUC, the only parameter you rely on from the policy fetch is the signature
type, correct? Another variant here could be to send an explicit policy fetch
request for google/chrome/extension/*. Doing so would accomplish to goals: (1)
We signal that we actually want extension policy blobs so the server doesn't
have to send them if they aren't requested and (2) we can specify the parameters
for the response, such as signature type. I acknowledge that this would be
another (minor) protocol change. Ignoring any other factors, do you think that's
a better approach from a technical perspective?

+      ids = self.server.ListMatchingComponents('google/chrome/extension')
+      for settings_entity_id in ids:
+        fake_request = dm.PolicyFetchRequest()
+        # Copy the user policy request, to trigger the same signature type
+        # in the response.

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

Regarding signatures, have you thought about what the right behavior is
regarding key rotations? I suspect we should just not perform any rotations for
extension policy blobs. Does it make sense to implement that here? If not -
please add a comment explaining what features of ProcessCloudPolicy we may get
but don't actually need.

[Joao da Silva, 2014/04/24 13:22:24]

Correct, we don't do rotations for extension policy blobs. These blobs are
verified with the same key as the main user policy blob; if that key is rotated
for the user policy blob that it is automatically rotated for extension policy
blobs too.

For completeness, here is what happens: when the server sends down a user policy
blob with a new key it should also send down the extension policy blobs signed
with the new key. The component-policy code reacts when the user
CloudPolicyStore is updated (indicating that the rotation was successful), and
then picks up the new extension policy blobs and caches them. However, the
remote policy data is not fetched again, since their hashes should still be the
same.

I've updated the code to just remove any fields related to key updates from
these responses.

[Mattias Nissler (ping if slow), 2014/04/24 13:38:25]

Ah, so this was a bit surprising to me - we do request user policy to be signed
with the old key, but extension policy comes back in the reply with the new key.
I guess that makes sense though as you should have the extension policy blobs
always signed with the *current* (as determined by the server) user policy key.
 

+        fake_request.CopyFrom(msg.policy_request.request[0])
+        fake_request.policy_type = 'google/chrome/extension'
+        fake_request.settings_entity_id = settings_entity_id
+        fetch_response = response.policy_response.response.add()
+        self.ProcessCloudPolicy(fake_request, token_info, fetch_response)
+
     return (200, response)
 
   def ProcessAutoEnrollment(self, msg):
     """Handles an auto-enrollment check request.
 
     The reply depends on the value of the modulus:
       1: replies with no new modulus and the sha256 hash of "0"
       2: replies with a new modulus, 4.
       4: replies with a new modulus, 2.
       8: fails with error 400.
@@ skipping 573 matching lines @@
       policy_selector: the policy type and settings entity id, joined by '/'.
 
     Returns:
       The filename corresponding to the policy_selector, without a file
       extension.
     """
     sanitized_policy_selector = re.sub('[^A-Za-z0-9.@-]', '_', policy_selector)
     return os.path.join(self.data_dir or '',
                         'policy_%s' % sanitized_policy_selector)
 
+  def ListMatchingComponents(self, policy_type):
+    """Returns a list of settings entity id that have a configuration file.

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

IDs (consistent with spelling below)

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+
+    Args:
+      policy_type: the policy type to look for. Only settings entity IDs for
+      file selectors that match this policy_type will be returned.
+
+    Returns:
+      A list of settings entity ID for the given |policy_type| that have a

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

IDs

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+      configuration file in this server (either as a .bin, .txt or .data file).
+    """
+    base_name = self.GetBaseFilename(policy_type)
+    files = glob.glob('%s_*.*' % base_name)
+    len_base_name = len(base_name) + 1
+    return [ x[len_base_name:x.rfind('.')] for x in files ]

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

s/x/file/

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+
   def ReadPolicyFromDataDir(self, policy_selector, proto_message):
     """Tries to read policy payload from a file in the data directory.
 
     First checks for a binary rendition of the policy protobuf in
     <data_dir>/policy_<sanitized_policy_selector>.bin. If that exists, returns
     it. If that file doesn't exist, tries
     <data_dir>/policy_<sanitized_policy_selector>.txt and decodes that as a
     protobuf using proto_message. If that fails as well, returns None.
 
     Args:
@@ skipping 115 matching lines @@
     if (self.options.log_to_console):
       logger.addHandler(logging.StreamHandler())
     if (self.options.log_file):
       logger.addHandler(logging.FileHandler(self.options.log_file))
 
     testserver_base.TestServerRunner.run_server(self)
 
 
 if __name__ == '__main__':
   sys.exit(PolicyServerRunner().main())