Add a DENY EXECUTE to Iron/Chrome Sandbox

Discussion in 'other software & services' started by Kees1958, Jul 26, 2010.

Thread Status:
Not open for further replies.
  1. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    High,

    We all know Iron/Chrome/Chromium has a well functioning Sandbox. Chrome only accesses its own registry keys, the user specific settings in Program Data (Vista/Win7), the temporaray folders and the download directory specified under the hood (wrench).

    To easily add a deny Access Control List for the Home Users see pictures 1 and 2

    STeps 1-6 : Add Home Users to Download directory
    press ok, ok, etc until screen of step 7 appears, select Home Users

    Steps 7-12: Deny execute rights for Home Users in Download Directory,
    ignore warning and press ok, ok, etc after step 12

    Make sure Chrome/Iron use this as download directory, without asking before download (Wrench, Options, 3rd tab = advanced options)

    Congratulations: you just raised the threshold for drive by infections when using UAC and Chrome
     

    Attached Files:

    • 1.png
      1.png
      File size:
      134.7 KB
      Views:
      71
    • 2.png
      2.png
      File size:
      133.1 KB
      Views:
      66
    • 3.png
      3.png
      File size:
      42.8 KB
      Views:
      1,141
    Last edited: Jul 26, 2010
  2. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
  3. bellgamin

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    Hola Kees-sensei,

    I always run as Admin (shame on me).

    Would it be just as effective to use any browser (Firefox, for example) in OnlineArmor's "Run Safer" mode?
     
  4. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    This will depend on whether the user account (your admin you are logged in as) has ownership to areas that the restricted token would normally be denied. It is the achilles heel of rights reduction, because while a reduced token (reduced from admin to user) would deny access to a specific object/container, if the user was the owner, there are no rights to restrict because the owner has full access.

    That is why Kafu was so popular with XP and SuRun, to try and correct things when the account that you installed everything with (admin) was reduced to a LUA.

    Clear as mud? lol.

    Sul.
     
  5. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Sul,

    Muddy waters indeed. To be safe I discovered that I needed an Admin account to install things (which was owner/creator) and another Admin account to run applications with reduced priveledges.

    This is as complex as running an Admin account on which you install things and running a LUA account (with elevation prompt for Admin rights) for normal activities. Because Windows prompts in 8 out of 10 cases for Admin rights the latter LUA was easier than using 2 admins.

    :D

    On our Windows7 Ultimate my wife runs LUA with a SRP deny on my XP Pro playing machine I run power user with aps running basic user and a SRP deny.

    Once getting used to LUA (we use Microsoft software mainly) the being of lightness (in terms of third party security overload) really is bonus
     
  6. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Yep, muddy is a good term to use.

    I haven't tried on 7 yet, but was never able to get a little tool to work that would eradicate this problem programatically. Maybe I will take a stab at it with win7, but I fear the undocumented features I was searching for in XP are still just as undocumented. Pity really, it would have changed the world, and probably eliminated global warming :D (or at the very least kept you from having to do it manually, which is always my goal).

    Sul.
     
  7. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Quite similar to what I have. I just have it a little more restricted. Even to get in my Downloads folder (I have one other, rather than Windows default one), things need my permission.

    By the way, one thing regarding ACLs.

    Obviously, you can remove permissions from a user(s) to a specific folder, like in this case, by selecting the opposite option DENY, in case the permissions are being inherited by the principal of the object.

    But, by removing the inheritance, the folder - whatever that may be - will lose the permissions that were inherited. Then, rather just selecting the opposite option (DENY), one could just select what to be allowed. Creating a white list of what objects within this folder could actually do.

    Would this be a simpler approach?

    For example:

    1. Take in consideration a LUA (Least-privileged User Account).

    Any object created within this type of account will inherit its permissions; what they do in the LUA (What the LUA allows them to do.).

    2. Considering the folder "Downloads".

    When we create a new folder, for example, and this case, the folder "Downloads", it will inherit LUA permissions.
    If we remove the selection from the "Include inheritable permissions from the principal of the object", then that folder will no longer inherit the LUA permissions. You may then only select what you wish to allow. Obviously, that means that everything else will be denied. But, instead of selecting the opposite option DENY, you'd be choosing ALLOW whatever you wish to allow. (Similar to SRP and AppLocker, if we think of it. SRP and AppLocker allow blacklist also.)

    By not inheriting the permissions from LUA (what the objects can do in a LUA environment) whatever is placed inside this "Downloads" folder has less rights than what is, for example, within "Program Files". Of course, you need to choose what not to ALLOW.

    As I said, one can just select the opposite option DENY. But, for what I've read some time ago, despite the fact most times DENY does take precedence over an ALLOW, it's not always like that.

    I'm not an expert in what comes to ACLs - I know enough, but always learning and digging - but this seems to work for me. Even changing the Owner of the object to an Admin, restricts changes to the permissions.
     
Loading...
Thread Status:
Not open for further replies.