Desktop privacy & security of web browsers on Linux part 1: concepts and theory
1–10 of 12 posts
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#2A problem with this particular approach is that chrome-trusted for example will no longer have access to the session's DBus, so it cannot show any notifications for example. And DBus, like X11, does not provide any separation right now as far as I'm aware (it has support for authentication, but in practice, `external` is used most of the time which is based on UID).
The only variant that might provide a real security benefit here is the -paranoid one, as that those not share the X11 server session.
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#3Improving Linux desktop security beyond "if you PWN one program, you PWN the whole desktop session" is going to be hard. X11 has no separation, so talking about this really only makes sense when using Wayland, which is no where near default yet. A problem with this particular approach is that chrome-trusted for example will no longer have access to the session's DBus, so it cannot show any notifications for example.…
Yes, X11 has no separation, but you can use multiple X11 isolated sessions, like i do in this config i'm explaining in this post.
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#4Improving Linux desktop security beyond "if you PWN one program, you PWN the whole desktop session" is going to be hard. X11 has no separation, so talking about this really only makes sense when using Wayland, which is no where near default yet. A problem with this particular approach is that chrome-trusted for example will no longer have access to the session's DBus, so it cannot show any notifications for example.…
Have you read the post? Yes, X11 has no separation, but you can use multiple X11 isolated sessions, like i do in this config i'm explaining in this post.
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#5Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#6Does someone run similar setup but with xpra + vm? Is it usable?
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#7Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#8Improving Linux desktop security beyond "if you PWN one program, you PWN the whole desktop session" is going to be hard. X11 has no separation, so talking about this really only makes sense when using Wayland, which is no where near default yet. A problem with this particular approach is that chrome-trusted for example will no longer have access to the session's DBus, so it cannot show any notifications for example.…
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#9This is pretty much what Firejail [1] does (except the page trust level) and using it is fairly straight forward. I had some issues running separate X server though (as far as I know, this is still more or less experimental feature). [1]: https://firejail.wordpress.com/
Re: Desktop privacy & security of web browsers on Linux part 1: concepts and theory
#10Improving Linux desktop security beyond "if you PWN one program, you PWN the whole desktop session" is going to be hard. X11 has no separation, so talking about this really only makes sense when using Wayland, which is no where near default yet. A problem with this particular approach is that chrome-trusted for example will no longer have access to the session's DBus, so it cannot show any notifications for example.…
Doesn't wayland take care of many of these concerns?
Wayland have some advantages but also some disadvantages, and it isn't yet really mature.
Also, wayland, on the sandbox side, doesn't do anything special. As it's just a lot simple than X and does pretty anything except copy a buffer on the screen, it just delegate all IPC and rendering to the compositor, then, in the wayland world, the security issues of X11 are moved on the compositor instead to stay on the X server, but the issue are the same and the compositor must consider them.