[SOLVED] Chrome 72 filling up .xsession-errors while watching YouTube

[trytip]

i decided to update my chrome browser since it's a "bad idea" not to. then i notice my .xsession-errors filled with these errors and size was getting larger than i seen it in quite a while.

ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.ScreenSaver.Inhibit: object_path= /org/freedesktop/ScreenSaver: unknown error type:

ERROR:power_save_blocker_x11.cc(330)] No response to Inhibit() request!

ERROR:object_proxy.cc(621)] Failed to call method: org.freedesktop.PowerManagement.Inhibit.Inhibit: object_path= /org/freedesktop/PowerManagement/Inhibit: unknown error type:

seems the more things get fixed the more they are broken. these errors are caused by watching youtube or other online videos. i also find out chrome developers disabled hardware acceleration in the process and is not available any longer.

would anyone be willing confirm that indeed they also get these .xsession-errors when using chrome/chromium version 71+ watching youtube?

[gm10]

Can't confirm with Chromium 72.x. Using something fun like firejail and its nonsensical default settings maybe which block dbus access? Because that's what that looks like.

[trytip]

duh.

why didn't i think of that. i tore up my nvidia and power management trying to get rid of this error and didn't even dawn on me about firejail. i'm using the github developer package, which i now have to get rid of. i was ok until the firejail developer mentioned not to use --ignore=nodbus since it breaches security. this is why you make the big bucks. thanx

[SOLVED]

[gm10]

Yep, the firejail guys have a hard-on for their dbus blocker, but if you want some usability then you better ignore that. If you went with their defaults on everything you'd catapult your system back into the stone ages. Besides, Chromium comes with its own seccomp sandbox so arguably using firejail on top isn't the greatest idea, anyway.

this is why you make the big bucks.

Haha, I wish.

[Fred Barclay]

The thing is, once you introduce dbus, you're assuming that any app should be able to talk to any other app. It's not that we're necessarily fond of nodbus, but that dbus, by definition, must be able to escape sandboxing (including firejail). As far as I'm aware there's no way to truly secure a sandbox and still allow dbus access. I really wish it wasn't so.

Besides, Chromium comes with its own seccomp sandbox so arguably using firejail on top isn't the greatest idea, anyway

You're absolutely correct -- which is why we don't add a seccomp sandbox for Chrome. We do have some other nice things like dropping all possible linux capabilities (we have to keep CAP_SYS_CHROOT and CAP_SYS_ADMIN, unfortunately), some file system protection,... and yes, dropping dbus. But we let Chrome's seccomp filter do its job without interfering.

[gm10]

As far as I'm aware there's no way to truly secure a sandbox and still allow dbus access. I really wish it wasn't so.

Dbus or any form of inter-process communication is by definition the opposite of sandboxing an app, so don't get me wrong, I fully understand the bind you are in there.

At the end of the day everybody has to find their own paranoia vs usability balance, and the paranoia part quite strongly depends on your personal attack profile analysis. If you run the browser with full scripting enabled, a bunch of untrusted, webapi enabled extensions in there, no content filtering, and you're surfing the some high risk sites while having your passwords stored in plain text in your documents folder, then you better run firejail in full paranoid mode, too (and even then it's a bad idea and you should rather throw the thing into a VM).

Myself, I believe I know how to use the browser responsibly and want to retain my usability at the cost of some additional risk, and that includes dbus access, being able to save/load files at least in all the non-hidden folders of my profile, etc. I am not aware of any malware that manages to access dbus from within a browser, either. So maybe not your typical customer. Nevertheless, keep up the good work!

[trytip]

adding this to the .bashrc will block additional logging to .xsession-errors it won't be nullified until the first time you open Terminal. logingOFF/ON returns .xsession-errors to normal until you open the Terminal again. this way i can monitor logging but i can stop it when watching youtube so it doesn't blindly dump all the dbus requests for inhibit.

Code: Select all

# If the .xsession-errors file is not a symbolic link, delete it and create it as such
if [ ! -h $HOME/.xsession-errors ]; then
rm $HOME/.xsession-errors
ln -s /dev/null $HOME/.xsession-errors
fi

[Fred Barclay]

Dbus or any form of inter-process communication is by definition the opposite of sandboxing an app, so don't get me wrong, I fully understand the bind you are in there.
...
Myself, I believe I know how to use the browser responsibly and want to retain my usability at the cost of some additional risk, and that includes dbus access, being able to save/load files at least in all the non-hidden folders of my profile, etc. I am not aware of any malware that manages to access dbus from within a browser, either. So maybe not your typical customer.

That makes sense. Definitely it's a balancing act between usability and security.

There was this little gem a while back: https://www.mozilla.org/en-US/security/ ... sa2015-78/ As far as I know it didn't need or access dbus, but it was problematic even on Linux systems. (Firejail did block it, btw.)

Nevertheless, keep up the good work!

We'll try! Thanks!

[gm10]

Firejail did block it, btw.)

Just because you're paranoid doesn't mean they aren't out to get you.

But for full disclosure, I do have an apparmor profile set up for my browser, I don't let it access just everything after all. But there's a lot of non-critical stuff I do like it to access, e.g. all the default media folders, my base home folder, things like that.

That said, it's no doubt easier to poke some "quality of life" holes into Firejail's existing profiles than setting up good apparmor profiles for all the software you use yourself.