Adding Command Flags to Chrome in Ubuntu?

Discussion in 'all things UNIX' started by Hungry Man, Mar 11, 2012.

Thread Status:
Not open for further replies.
  1. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I'm trying to enable seccomp sandbox but I can't. I've seen that if you edit google-chrome.desktop with the flag apparently this should work. I've done this though (I think? I had weird permissions issues) and still nothing.

    edit: I added it to a shortcut but seccomp still isnt working... is it not supported in ubuntu?
    edit2: Apparently seccomp is available only in chromium so I guess taht's what I'm using.

    Solved that on my own i guess lol
     
    Last edited: Mar 11, 2012
  2. x942

    x942 Guest

    Did you actually get it working? I can't get it to work anywhere. (chrome or chromium/stable or dev).

    When I look at chrome://sandbox/

    It displays:

     
  3. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Yeah, I did.

    I created a desktop shortcut, right clicked it, added the flag to properties.
     
  4. x942

    x942 Guest

    Finally got it to work. For some strange reason the short cut was readonly so every time I changed it it would revert back to having no flag.
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Is it working with Chrome?
     
  6. x942

    x942 Guest

    Chromium only still sadly. I am tempted to try the canary build of chrome to see if it will work with that. Maybe it's support is just upstream right now.
     
  7. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    There's a canary channel for Linux?

    I hadn't thought so.

    When seccomp comes to Chrome or Flash comes to 64bit Chrome I'll move back - for now I'll take seccomp chromium.
     
  8. x942

    x942 Guest

    hmm.. I haven't even looked yet. I just know it's not in the Dev build. Maybe there isn't a Canary build.

    I am running Chromium Dev with seccomp in a AntiX (Mepis variant) VM and it works quite well.
     
  9. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I was going to do some benchmarks at some point of Seccomp on and off. Apparently the way it works might hurt performance - it splits each process so that there are untrusted threads and trusted threads and it gets a bit complex but because of the communication being (essentially) doubled there can be a hit.
     
  10. tlu

    tlu Guest

    Adding

    --enable-seccomp-sandbox

    to Chrome 18 beta works.
     
  11. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Interesting. I'll try it again.

    edit: SEems to work now haha
     
  12. x942

    x942 Guest

    Woot! Just updated the Dev build to latest and now it works!
     
  13. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I think I wasn't properly restarting. Chrome runs background processes when it's closed and all of them need to be stopped and restarted for the seccomp sandbox to work.

    Either way, it's working now thankfully. I'm no longer using the AppArmor profile on the renderer but that's alright, seccomp is way more robust.
     
  14. x942

    x942 Guest

    It appears I was doing the same lol, some times the smallest things matter :p
     
  15. tlu

    tlu Guest

    How do you know that? Any evidence? I'm not aware of any trick/malware to circumvent AppArmor - are you?

    A sandbox is a good thing, no question. However, I don't see why FF tightly confined by its AppArmor profile should be less secure than Chrome.
     
  16. x942

    x942 Guest

    The only issue I know of is that app armor relies on hard links vs inode number. So if a file is accessed via a symbolic link or inode number it is not prevented by app armor.

    Which is why people often think SeLinux is more secure (although suffers from other issues).

    I know of no real-world attack that uses this but I know it is something to at least be wary of. I mean nothings 100% but it does decrease the attack vector significantly.
     
  17. tlu

    tlu Guest

    Thanks :thumb: Do you have a source for that?
     
  18. x942

    x942 Guest

  19. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    There are AppArmor bypasses (and SELinux bypasses for that matter.) AppArmor is pretty strong but it goes by name whereas SELinux actually labels the file or something.

    They both restrict IPC and file access and in general what the program can do.

    Seccomp is built in and goes beyond that, actually whitelisting what calls the program can make.

    It's just much more restrictive than AppArmor, though if you were so inclined you could make use of both.
     
  20. tlu

    tlu Guest

    My Chrome profile can be found here.

    EDIT: I forgot to add that I have some additional rules in /etc/apparmor.d/local/opt.google.chrome.google-chrome which I simply copied from my Chromium profile, e.g.

    /dev/nvidiactl rw,
    /dev/nvidia0 rw,
     
    Last edited by a moderator: Mar 18, 2012
  21. x942

    x942 Guest

    give's me this:

    Code:
    Setting /etc/apparmor.d/opt.google.chrome.google-chrome to enforce mode.
    Warning from stdin (line 1): /sbin/apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
    AppArmor parser error, in stdin line 129: Could not open 'local/opt.google.chrome.google-chrome'
    
    Won't run on my ubuntu machine at all.
     
  22. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I've had that happen, there's something invalid about the profile so the entire thing doesn't load.
     
  23. tlu

    tlu Guest

    Well, of course you get this error message if you don't have that file.;) As mentioned I have some additional rules in /etc/apparmor.d/local/opt.google.chrome.google-chrome (this is equivalent to the profiles delivered, e.g., for FF and Chromium). Simply create that file and leave it empty if you don't need additional rules specific for your system.

    EDIT: I forgot to mention that according to sudo aa-status ALL of my Chrome processes are in enforce mode.
     
    Last edited by a moderator: Mar 19, 2012
  24. tlu

    tlu Guest

    Hungry, there might be bypasses for AppArmor and SELinux theoretically. But quite frankly, that something will break out of my FF AppArmor profile is definitely the least of my sorrows.

    If you look at different types of risk, you have to weigh up each against the others. Risks like XSS, Clickjacking or CSRF are definitely much more relevant than theoretical attacks bypassing AppArmor - but a sandbox simply doesn't protect against them. And I seriously doubt that Chrome protects against them better than FF (with Noscript). I think Chrome does not protect against Clickjacking, and I've come across some XSS examples where the Chrome XSS filter didn't react but Noscript did.

    So ... the exclusive focus on the sandbox is not conducive. A more holistic view is the better approach. IMHO.
     
  25. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I've seen videos of AppArmor breakouts, same for SELinux.

    I agree that there needs to be risk assessment though. An exploit breaking though both Firefox and AppArmor doesn't seem very likely, especially since automated attacks on Linux are few and far between. And attack breaking through even Chrome's SUID sandbox seems unlikely, though I enjoy knowing that breaking through the SUID and Seccomp sandbox is even harder.

    The thing about XSS, Clickjacking, and/ or CSRF is that their primary goal is to "infect" a webpage and then have that webpage infect you or socially engineer a situation (redirection to a fake facebook page) that leads to my information being stolen.

    For one of those situations sandboxing is key, it keeps me from being infected. For the other, I agree, sandboxing is of no help.

    Chrome does nto protect against clickjacking. ScriptNo protects against it somewhat, but not in the same way as Firefox's NoScript.
     
Loading...
Thread Status:
Not open for further replies.