New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2010
Cc:
EstimatedDays: ----
NextAction: ----
OS: Win7
Pri: 2
Type: Bug
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome doesn't work with Win7 & AppLocker

Reported by gwilson@chromium.org, Apr 15 2009

Issue description

On Windows 7,

1. Enable AppID
2. Create default Exe rules and also create a path rule to allow everything 
under "%osdrive%\users\<user>\appdata\local\google\*"
3. Launch Chrome

Not able to browse any site!

Event viewer logged one allow event and one deny event for chrome.exe

If you see the event viewer you will find two events:  one where chrome is 
allowed and the other where chrome is denied. For the first instance, the 
matching rule is the path rule that you created for AppData, but the second 
instance is denied by the default deny rule.  

This is probably because Chrome's renderer process is created with 
CreateProcessAsUserW and matches the "deny" flags being set.


 
Labels: Mstone-X
Status: Available
I don't have a good milestone for Win7 specific issues, yet.
Labels: Mstone-4

Comment 3 by Deleted ...@, Aug 18 2009

I confirm it on 4.0.201.1. This should have been fixed long time ago.
Add label: Assigned/Started.
Status: Assigned

Comment 7 by cpu@chromium.org, Oct 26 2009

I can't repro this following the above steps. Do I need to reboot?

Labels: -Mstone-4 Mstone-5
Status: Available
Mstone-5 if it can't be repro.

Comment 9 by natemc...@gmail.com, Nov 12 2009

I am experiencing this issue with Chrome installed via Google Pack on Windows 7 RTM
(64-bit). Should be able to repro like so:

1. Create AppLocker default Executable rules
2. Configure Applocker enforcement and enable enforcement for Executable rules
3. Install Chrome via Google Pack so it is installed under c:\program files
(x86)\Google\... -  AppLocker path will be
%PROGRAMFILES%\GOOGLE\CHROME\APPLICATION\CHROME.EXE
4. Run Chrome.
5. The main window will be created.
5. Type something in the address bar. Suggest items will appear but attempts to load
any page result in the about:blank page being displayed.
6. AppLocker event logs will show %PROGRAMFILES%\GOOGLE\CHROME\APPLICATION\CHROME.EXE
being allowed to run once, then denied for any page load attempt.
7. Run chrome.exe with --no-sandbox switch.
8. Pages should load normally.

Note that prior to enabling Applocker I had been using equally restrictive software
restriction policies (default deny mode) and Chrome was running without issue. Also
note that with AppLocker the above results remain the same whether running as an
unprivileged user and as an administrative whether or not Chrome was run with
elevated privileges.
I forgot a step in the previous post. You also need to enable and start the Windows
"Application Identity" service for the rules to actually start being enforced. There
should be no need for a reboot or logout if memory serves. This should done
immediately after rule enforcement is enabled (step 2).
Status: Assigned
Sounds like it might need to be a system-level install...maybe that's why we couldn't 
repro before?
I don't think it would be specific to either install method. When you attempt to 
repro are you seeing any allow or deny messages in the AppLocker logs? Evidently 
something about the way Chrome's sandboxing is performed appears to AppLocker like 
Chrome is trying to launch processes outside of the paths that are allowed. What is 
strange is that the deny log messages reference the regular chrome.exe path which is 
allowed (whih is confirmed by allow log entries).

Comment 13 by oritm@chromium.org, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Labels: Internals-Install
Labels: -Area-Internals -Internals-Install
Fixing a bulk edit. Looks like the search query was not correct.

Comment 16 by ahod...@gmail.com, Jan 8 2010

File hash and signature AppLocker rules don't work to fix this issue either, so it's
definitely not just a file path issue.  As always, both the allowed and denied event
in the event log show the correct hash, signature, and file path that was added to
the Allow rule.

Comment 17 by cpu@chromium.org, Jan 8 2010

I'll take a look at this in the next two weeks. Else I'll ask Nick for help.
(I haven't really looked at the problem, but from looking at the description, I might 
have an idea)

For the renderer to start on win7 64bit, we need to launch wow_helper.exe (which is in 
the same directory as chrome.exe). Can you make sure this is also in the trusted list?

thanks

Comment 19 by ahod...@gmail.com, Jan 8 2010

I have a system-wide install and have the entire Program Files directory on the white
list.  Explicitly adding wow_helper.exe to the AppLocker trusted list didn't change
anything.  Looking through the AppLocker log shows no reference (allowed or denied)
to wow_helper.exe, so it must not be getting that far.  I can give this a try on a
32-bit Windows 7 install later to see if there's any difference.
that would be really interesting to know if it works on 32 bit. thanks.


Comment 21 by ahod...@gmail.com, Jan 8 2010

Doesn't work on 32-bit.  I think this is related to the group filtering that's being
done on the access tokens.  There's a deny flag on every group including the
"Everyone" group, so none of the rules in AppLocker would match if I understand
correctly.  When running with --no-sandbox, none of these groups are masked out.

I tried modifying the AppLocker rule in the registry to change the user to S-1-0-0
(NULL SID), but it didn't help (it wouldn't accept it in the GUI, so it probably just
isn't supported).

I came across a flag in CreateRestrictedToken that disables AppLocker checks
(SANDBOX_INERT): http://msdn.microsoft.com/en-us/library/aa446583%28VS.85%29.aspx. 
Other than that, maybe just leaving the Everyone group SID enabled might work.

Comment 22 by cpu@google.com, Jan 9 2010

@21: wow, CreatedRestrictedToken has been finally documented and it has more flags 
now!!!

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=35990 

------------------------------------------------------------------------
r35990 | cpu@chromium.org | 2010-01-11 18:54:30 -0800 (Mon, 11 Jan 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/restricted_token.cc?r1=35990&r2=35989

Try the SANDOX_INERT flag in CreateRestrictedToken
- It might help with the AppLocker problem. See bug below.

BUG= 10576 
TEST=existing tests suffice


Review URL: http://codereview.chromium.org/541018
------------------------------------------------------------------------

Comment 24 by cpu@chromium.org, Jan 12 2010

ahodes1, nsylvain, natemckay, gwilson

I landed the sandbox_inert flag yesterday. I want to see if one of you can check if this 
helps. 

You can pick a build from anytime today from here
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

Nicolas, is that the best way to get a fresh chromium?

This path is better :  http://build.chromium.org/buildbot/continuous/LATEST/

(The difference is that this path contains the last build that passed all the tests, so 
there are more chances that it will work).
I tried the new build, and it works fine for me. (After fighting with the AppLocker 
policy for a lot more time than I really wanted to). I added the whole chrome path in 
the allowed list. Adding just chrome.exe made it fail on wow_helper.exe.  It might work 
if you just add those 2 files manually.

Remember that chrome.exe on the chromium.org website is not signed, so you can't used 
the publisher policy, you need to use the path policy. (or checksum, but I don't 
suggest that)

Comment 27 by ahod...@gmail.com, Jan 12 2010

Works fine for me now as well.
Ditto, it appears to be working normally now. AppLocker logs show both chrome.exe and 
wow_helper.exe being allowed to run. Tested on Win7 RTM 64-bit.

Comment 29 by cpu@chromium.org, Jan 13 2010

Status: Fixed
Awesome. Sorry it took this long. Thanks to ahodes1 for the hint that allowed to solve 
the mystery.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=36132 

------------------------------------------------------------------------
r36132 | laforge@chromium.org | 2010-01-13 09:39:57 -0800 (Wed, 13 Jan 2010) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249/src/sandbox/src/restricted_token.cc?r1=36132&r2=36131

Merge 35990 - Try the SANDOX_INERT flag in CreateRestrictedToken
 It might help with the AppLocker problem. See bug below.

BUG= 10576 
TEST=existing tests suffice


Review URL: http://codereview.chromium.org/541018

TBR=cpu@chromium.org
Review URL: http://codereview.chromium.org/550029
------------------------------------------------------------------------

Project Member

Comment 31 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 32 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-5 M-5
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment