Cleanup/Remove Windows XP/Vista version checks from Windows sandbox code

sandbox/win/src/win_utils.cc

 // Copyright (c) 2011 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 "sandbox/win/src/win_utils.h"
 
 #include <stddef.h>
 
 #include <map>
 
@@ skipping 180 matching lines @@
           error != ERROR_PATH_NOT_FOUND &&
           error != ERROR_INVALID_NAME) {
         // Unexpected error.
         if (passed_once && added_implied_device &&
             (path.rfind(L'\\') == kNTDotPrefixLen - 1)) {
           break;
         }
         NOTREACHED_NT();
         return error;
       }
-    } else if (FILE_ATTRIBUTE_REPARSE_POINT & attributes) {
+    }/* else if (FILE_ATTRIBUTE_REPARSE_POINT & attributes) {
       // This is a reparse point.
       return ERROR_SUCCESS;
-    }
+    }*/

[kylix_rd, 2016/03/17 23:49:31]

According to this:
https://bugs.chromium.org/p/project-zero/issues/detail?id=486&redir=1

The issue behind why this code is here has been fixed. Is there anyway to check
whether the currently running kernel is properly patched? This code only needs
to run if the unpatched/fixed kernel is present.

One idea was to have the sandboxed process actually try the exploit early in the
startup and fail if it is successful.. of course that places the exploit code
into the product.. probably not a good thing.

Don't know if there are ways to check the kernel patch level... that may also be
by design so that exploits can't easily tune their code at runtime.

[Will Harris, 2016/03/18 05:17:04]

I think we should leave this check in.

[jschuh, 2016/03/18 07:03:23]

kylix_rd  - Sorry, I should have paid closer attention to your question earlier.
This code has nothing to do with forshaw's PZ bug. Rather, this supports a very
early sandbox design decision. That is, sandbox policies are path based, and if
you allow reparse points then filesystem policies get much harder to reason
about. So, the sandbox explicitly refuses to apply policies to paths with
reparse points.

Normally that approach isn't a problem, because we make very little use of
filesystem policies. However, if you look at the uses of AddRule in
sandbox_win.cc you'll see that unofficial and debug builds add a collection of
policies to enable logging and debugging in custom builds. So, that's what
you're running into.

In the future it would probably be easier to carry local changes in a local
branch that you base your CL off of. That way they won't be included in the CL
you post for review.

[kylix_rd, 2016/03/18 14:08:53]

Ok, that makes sense.

Something to think about; What about systems where there are
policies/configurations where "Program Files" are redirected through reparse
points or other such tricks? This may become more common as people use SSDs for
their boot drive, but then junction/symlink to their spindled drives for
programs and larger storage. This is how I've configured my system at home. I've
also used junctions to "graft in" an SSD into a folder off "C:" for development.
OS on spindle, development on SSD.

I only bring this up as something that may need to be considered in the future.
I'll also concede that this may become moot as SSDs get larger and prices
continue to drop.

 
     passed_once = true;
     last_pos = path.rfind(L'\\');
   } while (last_pos > 2);  // Skip root dir.
 
   return ERROR_NOT_A_REPARSE_POINT;
 }
 
 // We get a |full_path| of the forms accepted by IsReparsePoint(), and the name
 // we'll get from |handle| will be \device\harddiskvolume1\some\foo\bar.
@@ skipping 204 matching lines @@
     ::InterlockedCompareExchangePointer(
         reinterpret_cast<PVOID volatile*>(&ntdll), ntdll_local, NULL);
 
   }
 
   CHECK_NT(ntdll);
   FARPROC* function_ptr = reinterpret_cast<FARPROC*>(ptr);
   *function_ptr = ::GetProcAddress(ntdll, name);
   CHECK_NT(*function_ptr);
 }