Adding Command Flags to Chrome in Ubuntu?

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

 

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:

 

Yeah, I did.

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

 

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.

 

Is it working with Chrome?

 

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.

 

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.

 

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.

 

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.

 

Adding

--enable-seccomp-sandbox

to Chrome 18 beta works.

 

Interesting. I'll try it again.

edit: SEems to work now haha

 

Woot! Just updated the Dev build to latest and now it works!

 

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.

 

It appears I was doing the same lol, some times the smallest things matter

 

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.

 

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.

 

Thanks Do you have a source for that?

 

Just general reading and wikipedia. http://en.wikipedia.org/wiki/Apparmor

I used to have an url to a white paper where I first heard of it. But I don't seem to be able to find it.

If anyone does find it please post!!

It may not apply any more but to my knowledge it does.

EDIT: heres a comparison I found: http://www.suse.com/support/security/apparmor/features/selinux_comparison.html

 

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.

 

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,

 

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.

 

I've had that happen, there's something invalid about the profile so the entire thing doesn't load.

 

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.

 

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.

 

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.