Isolating Xwayland in a VM(roscidus.com)
roscidus.com
Isolating Xwayland in a VM
https://roscidus.com/blog/blog/2021/10/30/xwayland/
53 comments
There's also a project[1][2][3] to allow Windows-like containers inside, based on the ReactOS.
[1] https://github.com/QubesOS/qubes-issues/issues/2809
[2] https://reactos.org/forum/viewtopic.php?t=16480
[3] https://github.com/Jeeppler/QubesOS-notes/blob/master/ReactO...
[1] https://github.com/QubesOS/qubes-issues/issues/2809
[2] https://reactos.org/forum/viewtopic.php?t=16480
[3] https://github.com/Jeeppler/QubesOS-notes/blob/master/ReactO...
This is very very cool. I had coincidentally just spent my evening trying to figure out how to get Wayland and Sommelier working in a slightly odd environment (Crouton, on Chrome OS), and this article showed up on HN just in time for me to appreciate it :)
Just curious, why did you set that up on crouton vs just using crostini?
It should be noted that Qubes is thus far the only actually secure X environment.
The hardware X server runs in a secure X VM, which has exclusive access to input devices, the GPU, and the physical frame buffer memory. (Ordinary X gives all programs access to all traffic from all input devices, and the whole frame buffer.)
Each client VM runs an X server that really only manages window contents. These windows are mmapped to memory the secure X VM exposes from its address space, It copies pixels from the shared regions to the real frame buffer. UI events that happen in each such window are forwarded to the client VM that owns it.
Regular desktop "panel" widgets and other UI stuff is managed by the secure X VM.
USB devices can be attached, via the secure X UI, to a chosen client VM, or taken back. Likewise, input devices such as microphones. The VM only gets PulseAudio streams forwarded from a microphone, and has no access to the sound chip.
The only awkward thing is that client VMs have no access to any GPU acceleration. This is not a problem for normal use -- browsers all can use CPU-only graphics modes, and they are fast enough for the usual things, including youtube videos, albeit with increased power consumption.
The hardware X server runs in a secure X VM, which has exclusive access to input devices, the GPU, and the physical frame buffer memory. (Ordinary X gives all programs access to all traffic from all input devices, and the whole frame buffer.)
Each client VM runs an X server that really only manages window contents. These windows are mmapped to memory the secure X VM exposes from its address space, It copies pixels from the shared regions to the real frame buffer. UI events that happen in each such window are forwarded to the client VM that owns it.
Regular desktop "panel" widgets and other UI stuff is managed by the secure X VM.
USB devices can be attached, via the secure X UI, to a chosen client VM, or taken back. Likewise, input devices such as microphones. The VM only gets PulseAudio streams forwarded from a microphone, and has no access to the sound chip.
The only awkward thing is that client VMs have no access to any GPU acceleration. This is not a problem for normal use -- browsers all can use CPU-only graphics modes, and they are fast enough for the usual things, including youtube videos, albeit with increased power consumption.
Amazing! Thank you for sharing. I have to admit that I lack a lot in security related stuff. Reading your post is inspiring. I am thinking about experimenting with proxmox to run a similar setup.
Currently I isolate each customer in its own vm. This works well but comes with the overhead to run a remote session for each customer. Using your method I could have a much more streamlined work flow while maintaining a high level of isolation.
Spectacular article, I couldn’t express more gratitude for the deep context provided around every piece.
Useful approach, given the troves of applications that cannot be ported to the native Wayland in years to come - all GTK2 apps, e.g. GIMP, all Java apps, and so on...
Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers.
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers.
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
> PR that so far is being ignored by the Wayland developers
The reviewers have asked for some details about the changes and no response yet, it seems unfair to blame the maintainers here.
But of course that goes against the narrative of "Wayland bad".
The reviewers have asked for some details about the changes and no response yet, it seems unfair to blame the maintainers here.
But of course that goes against the narrative of "Wayland bad".
I never said "Wayland is bad". Some cases aren't handled properly before making it mainstream in Linux distributions. It should have been done before, not after.
Open source doesn't really work like that, there is no top-down decision maker setting priorities for what should be done in any given distribution. Usually what happens is you wait until it becomes enough of a problem that some distribution fixes it, but this one is low priority given that distributions would probably prefer to focus on native Wayland ports for the software they have control over that is packaged in their distribution. And for the external software they don't have control over, it's much harder to find people to work on those.
^ further, there's the fact that distributions (and the various parts therein) frequently duplicate one another's work in the name of taking different approaches at the same problem, and usually the solutions that become more mainstream are the ones that several of them have collectively settled on.
Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.
Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.
Java does not depend on Gtk 2, unless you're stuck with some pre-historic version.
As for Wayland,
https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...
As for Wayland,
https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...
I know, those were two separate categories. Regarding the Wayfield project, citing them:
> It is very unlikely that distros will be ready to ship all the pieces we need in the next 12 months. So the "short term" goal may actually need to wait for somewhat longer than that.
https://wiki.openjdk.java.net/display/wakefield/Meeting+Note...
> It is very unlikely that distros will be ready to ship all the pieces we need in the next 12 months. So the "short term" goal may actually need to wait for somewhat longer than that.
https://wiki.openjdk.java.net/display/wakefield/Meeting+Note...
Given the progress adopting Wayland I don't see that much of a problem that it will take some time to deliver a full working solution.
The way you made your remark could be understood as if nothing was being done at all.
The way you made your remark could be understood as if nothing was being done at all.
It's indeed not a problem if the Wayland sessions wouldn't become the default in mainstream distributions and these pesky HiDPI displays didn't become more affordable and popular among users.
Don't get me wrong, the blame is squarely on the Java ecosystem that is too slow to keep up with the progress, Wayland developers did great job. The problem is that we still use some of that Java software, or some of that GTK2 software (GIMP), so it's better to accomodate the needs of that software, even if just temporarily.
Don't get me wrong, the blame is squarely on the Java ecosystem that is too slow to keep up with the progress, Wayland developers did great job. The problem is that we still use some of that Java software, or some of that GTK2 software (GIMP), so it's better to accomodate the needs of that software, even if just temporarily.
Other than ChromeOS and WSL, hardly any distribution is Wayland only, so one can't really blame the Java community to focus improving Swing on Wayland, specially with other more relevant areas still in need.
If anything the whole GNU/Linux ecosystem is too slow adopting Wayland.
If anything the whole GNU/Linux ecosystem is too slow adopting Wayland.
That's my MR and I haven't had time to complete it (particularly a compositor impl to go along with it), has nothing to do with being ignored.
> particularly a compositor impl to go along with it
Well, there is a wlroots impl, so I've just added a couple lines to wlroots to invoke this support from an env variable without having to modify the actual compositor :D
https://github.com/unrelentingtech/wlroots/commit/5b8308651c...
but the wlroots impl isn't merged either, so I think there's kind of a mutual dependency here. Either your MR or the wlroots MR should go in first!
Well, there is a wlroots impl, so I've just added a couple lines to wlroots to invoke this support from an env variable without having to modify the actual compositor :D
https://github.com/unrelentingtech/wlroots/commit/5b8308651c...
but the wlroots impl isn't merged either, so I think there's kind of a mutual dependency here. Either your MR or the wlroots MR should go in first!
> Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers.
Just curious, what are the Wayland developers expected to do? This seems like an Xwayland and compositor implementation issue.
Just curious, what are the Wayland developers expected to do? This seems like an Xwayland and compositor implementation issue.
[deleted]
> ignored by the Wayland developers
Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.
Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.
To be honest, it's not very important to me - I need this particular case on the one machine where I use JetBrains IDE. On this machine I just switched to the Xorg. Everywhere else, I am quite happy with the pure Wayland as is, kudos to developers. It is important [1] for many JetBrains users, it seems though.
[1] https://youtrack.jetbrains.com/issue/JBR-3206
[1] https://youtrack.jetbrains.com/issue/JBR-3206
This is a bit off topic, but the article reminded me of something that's always bothered me: one of the (several) motivations for creating Wayland was to fix the security issues with X11, namely that any X client can read and manipulate the windows belonging to any other X client. And I've heard claims that this problem is just unsolvable.
It... doesn't seem like it is, really. Couldn't we modify the X server so clients just can't do that anymore? And then introduce a new X extension that provides for cases where this does need to happen, like the window manager (which could be granted blanket permissions), and other apps that would cause a dialog to pop up where the user could approve or deny access (think apps that take screenshots, or video conferencing apps that share the screen or specific windows with other participants). This permissions dialog could be handled by the window manager, or perhaps some standalone app that is somehow securely registered with the X server via this new X extension.
I expect there are some other issues (and things that will break[0]) with apps not knowing about other apps' windows, but I'm not convinced those issues can't be solved. I could even imagine that this new regime might only implement partial isolation, where clients can't read pixels from or fake events to other clients' windows (among other things), but can know the sizes and positions of other windows, and maybe even read some whitelisted set of window properties. I think that would still address most, if not all, security concerns with the current model.
(Just to present some credentials so this doesn't come off as a clueless, "duh, this is so easy, you morons"-type post: I've written an X11 compositor, hacked on a window manager, built a simple toy WM for fun, and was once a co-maintainer of a reasonably popular desktop environment. So I'm not a complete noob here.)
Certainly there are other benefits to Wayland over X11, not just security: greatly simplifying the graphics situation, moving the compositor into the "server" where IMO it belongs, etc. But I'm still not completely sold on the idea that this is worth a multi-decade project to completely replace this critical bit of the Linux GUI stack.
I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies. Of course, at the end of the day, I'm not doing the work, and the nature of open source means that if everyone wants to work on Wayland and no one wants to work on X11 or the xorg server, that's just the way it will be. But it feels like if we'd put even a fraction of the Wayland effort toward making X11 better, we'd be done by now, and people writing X11 applications would mostly not have had to do all that much work to migrate (and many wouldn't have to do any). Would it be as objectively "good" as Wayland supposedly is? No, probably not, but perhaps that doesn't matter.
[0] One thing I can think of here is that some applications need to open more than one connection to the X server, and the X server would see them as separate clients. That could break an application that expects to be able to share and manipulate resources between the multiple connections. But perhaps that could be worked around by grouping permissions not solely by connection, but by process ID. There are probably still some edge cases here, but I think changing the apps here would be ok to do; at least, it seems like less work to accept this sort of breakage and try to fix the apps rather than develop an entirely new windowing system!
It... doesn't seem like it is, really. Couldn't we modify the X server so clients just can't do that anymore? And then introduce a new X extension that provides for cases where this does need to happen, like the window manager (which could be granted blanket permissions), and other apps that would cause a dialog to pop up where the user could approve or deny access (think apps that take screenshots, or video conferencing apps that share the screen or specific windows with other participants). This permissions dialog could be handled by the window manager, or perhaps some standalone app that is somehow securely registered with the X server via this new X extension.
I expect there are some other issues (and things that will break[0]) with apps not knowing about other apps' windows, but I'm not convinced those issues can't be solved. I could even imagine that this new regime might only implement partial isolation, where clients can't read pixels from or fake events to other clients' windows (among other things), but can know the sizes and positions of other windows, and maybe even read some whitelisted set of window properties. I think that would still address most, if not all, security concerns with the current model.
(Just to present some credentials so this doesn't come off as a clueless, "duh, this is so easy, you morons"-type post: I've written an X11 compositor, hacked on a window manager, built a simple toy WM for fun, and was once a co-maintainer of a reasonably popular desktop environment. So I'm not a complete noob here.)
Certainly there are other benefits to Wayland over X11, not just security: greatly simplifying the graphics situation, moving the compositor into the "server" where IMO it belongs, etc. But I'm still not completely sold on the idea that this is worth a multi-decade project to completely replace this critical bit of the Linux GUI stack.
I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies. Of course, at the end of the day, I'm not doing the work, and the nature of open source means that if everyone wants to work on Wayland and no one wants to work on X11 or the xorg server, that's just the way it will be. But it feels like if we'd put even a fraction of the Wayland effort toward making X11 better, we'd be done by now, and people writing X11 applications would mostly not have had to do all that much work to migrate (and many wouldn't have to do any). Would it be as objectively "good" as Wayland supposedly is? No, probably not, but perhaps that doesn't matter.
[0] One thing I can think of here is that some applications need to open more than one connection to the X server, and the X server would see them as separate clients. That could break an application that expects to be able to share and manipulate resources between the multiple connections. But perhaps that could be worked around by grouping permissions not solely by connection, but by process ID. There are probably still some edge cases here, but I think changing the apps here would be ok to do; at least, it seems like less work to accept this sort of breakage and try to fix the apps rather than develop an entirely new windowing system!
> one of the (several) motivations for creating Wayland was to fix the security issues with X11
security was only a footnote in the list of arguments of why X has/had to go.
X11 maintainer Daniel Stone's[0] very funny but also educational talk[1] from 2013 linux.conf.au has a lot of the gory details that make you say thank fuck and good riddance. The talk will make you feel truly grateful instead of nostalgic. Anyone who missed the 3 decade long discussion of why X is bad give it a go (it'll put good cheer in your heart I promise).
> I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies.
it's not about whether anyone _can_ but if anyone should and is willing to do so is the right question (that Daniel's talk answers).
BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
[0] https://www.fooishbar.org/about/
[1] https://www.youtube.com/watch?v=RIctzAQOe44
security was only a footnote in the list of arguments of why X has/had to go.
X11 maintainer Daniel Stone's[0] very funny but also educational talk[1] from 2013 linux.conf.au has a lot of the gory details that make you say thank fuck and good riddance. The talk will make you feel truly grateful instead of nostalgic. Anyone who missed the 3 decade long discussion of why X is bad give it a go (it'll put good cheer in your heart I promise).
> I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies.
it's not about whether anyone _can_ but if anyone should and is willing to do so is the right question (that Daniel's talk answers).
BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
[0] https://www.fooishbar.org/about/
[1] https://www.youtube.com/watch?v=RIctzAQOe44
> BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
Provide an X server :-P.
The Unix Philosophy not only isn't really a philosophy but also isn't meant to be a dogma - it is meant to be a guideline that, when it makes sense, can be bent.
For example not even the original Unix kernel followed the Unix philosophy because sometimes you need some programs to do more than one things - often in order to enable other programs focus on their "do one thing well" aspect (e.g. window managers).
Provide an X server :-P.
The Unix Philosophy not only isn't really a philosophy but also isn't meant to be a dogma - it is meant to be a guideline that, when it makes sense, can be bent.
For example not even the original Unix kernel followed the Unix philosophy because sometimes you need some programs to do more than one things - often in order to enable other programs focus on their "do one thing well" aspect (e.g. window managers).
>so what is the 1 thing X does, and what is it doing well?
That... Isn't entirely fair. UNIX Philosophy is usually applied at the program level. You're talking the entire X stack, which, like it or not, started as "Network agnostic graphical computing" which was composed out of a handful of programs, and a protocol.
Now. We all know it isn't that now; and I don't buy that it's all X's fault. You have what, going on 40 years worth of dead ends there, that obviously someone thought was going to be important at some point, but which also were emergent outcomes of a bunch of companies doing, among other things, pursuing their own ends without tipping their hand to everyone else trying to yoink an idea or two. If you don't think X suffered for it, I'd like to point you at the rats nest of abstractions you end up having to navigate. And no, a compositor doesn't magically make it go away. Further, how many people here discussing/developing/opining have read, understood and reasoned about the source as a whole to the point of actually getting something working?
I'd wager not many. Next time I have a few months, it's on my TODO list. I have gone through the X.Org Dev docs a couple times though. Need to probably print it out and do some bookmarking to build up my haptic recall model for it.
That... Isn't entirely fair. UNIX Philosophy is usually applied at the program level. You're talking the entire X stack, which, like it or not, started as "Network agnostic graphical computing" which was composed out of a handful of programs, and a protocol.
Now. We all know it isn't that now; and I don't buy that it's all X's fault. You have what, going on 40 years worth of dead ends there, that obviously someone thought was going to be important at some point, but which also were emergent outcomes of a bunch of companies doing, among other things, pursuing their own ends without tipping their hand to everyone else trying to yoink an idea or two. If you don't think X suffered for it, I'd like to point you at the rats nest of abstractions you end up having to navigate. And no, a compositor doesn't magically make it go away. Further, how many people here discussing/developing/opining have read, understood and reasoned about the source as a whole to the point of actually getting something working?
I'd wager not many. Next time I have a few months, it's on my TODO list. I have gone through the X.Org Dev docs a couple times though. Need to probably print it out and do some bookmarking to build up my haptic recall model for it.
This. Anyone who is thinking of posting "but muh network transparency" or some other tired old argument needs to stfu, watch Daniel Stone's talk, and realize that literally everyone with knowledge of the Linux graphics stack feels the exact same way. X is the internal combustion engine of window systems: it's really bad and it's got to go; give or take epsilon literally 100% of domain experts have known it's got to go for decades; yet here we are still stuck with it.
You WILL be running a Wayland desktop in the near future. Xorg itself is already unmaintained abandonware. The next step is deprecating and removing X support from the major toolkits. Beyond that, who knows. Probably Xwayland itself will be deprecated and removed too.
Best to suck it up, burn your X config to the ground, and start afresh with Wayland. If it's janky, submit bug reports or PRs. Just rip the band-aid off already, because nobody wants to hear your hemming and hawing when the axe finally comes for X.
You WILL be running a Wayland desktop in the near future. Xorg itself is already unmaintained abandonware. The next step is deprecating and removing X support from the major toolkits. Beyond that, who knows. Probably Xwayland itself will be deprecated and removed too.
Best to suck it up, burn your X config to the ground, and start afresh with Wayland. If it's janky, submit bug reports or PRs. Just rip the band-aid off already, because nobody wants to hear your hemming and hawing when the axe finally comes for X.
The linked talk is full of half truths and misinformation by omission and already was when I first watched it in 2013. Most significantly the speaker conflates the X protocol and Xlib which nobody was using to write new software even back then. He says that gedit performs lots of blocking calls during startup. That's a problem of Xlib. With XCB you can perform all of these calls in parallel. He says that referring to an object that doesn't exist causes your program to abort by default. That's a problem of Xlib. With XCB, this simply returns an error that you can handle like you would do with any other API. He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.
I'm not going to go over the whole video since it was primarily made for entertainment and therefore any point can be defended by "he was exaggerating for comedic effect". Invoking this video is akin to invoking late night tv hosts when talking about politics.
And then of course he also has some valid points which are unfortunately diminished because the uninformed watcher will not be able to distinguish them for the invalid points.
I'm not going to go over the whole video since it was primarily made for entertainment and therefore any point can be defended by "he was exaggerating for comedic effect". Invoking this video is akin to invoking late night tv hosts when talking about politics.
And then of course he also has some valid points which are unfortunately diminished because the uninformed watcher will not be able to distinguish them for the invalid points.
>conflates the X protocol and Xlib which nobody was using to write new software even back then.
They are mostly synonymous, there is a large amount of software using Xlib that will likely not ever be rewritten to use XCB. And Xlib is still a better option than XCB if you want to use any client libraries because those all require Xlib.
>He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.
With GTK applications like gedit, it actually is because those are in the category of "won't ever be updated to use XCB". IIRC somebody even tried to port GTK to XCB once and the patches were never merged because it broke everything. XCB is nice for some things but comes with its own set of issues. Please also keep in mind that if you're suggesting the only reasonable solution is to rewrite every client to use a new library, that comes with about the same difficulty as porting to Wayland.
They are mostly synonymous, there is a large amount of software using Xlib that will likely not ever be rewritten to use XCB. And Xlib is still a better option than XCB if you want to use any client libraries because those all require Xlib.
>He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.
With GTK applications like gedit, it actually is because those are in the category of "won't ever be updated to use XCB". IIRC somebody even tried to port GTK to XCB once and the patches were never merged because it broke everything. XCB is nice for some things but comes with its own set of issues. Please also keep in mind that if you're suggesting the only reasonable solution is to rewrite every client to use a new library, that comes with about the same difficulty as porting to Wayland.
There's also the little discussed part that XFree86/X.Org was the lowest common denominator implementation, and never really put resources into fixing many issues, while creating various problematic workarounds over time. And lo, toolkits ended up pushing for more and more "just let me blit"...
Meanwhile Wayland's design results in people writing hotkeys as root-running programs that hijack input devices at low level, because the whole system is incapable of providing such feature in pluggable way...
Meanwhile Wayland's design results in people writing hotkeys as root-running programs that hijack input devices at low level, because the whole system is incapable of providing such feature in pluggable way...
Any mechanism that allows you to listen to hotkeys at will is about as insecure as running a program as root that snoops keys; either way you're vulnerable to keyloggers. The X implementation is quite insecure as well as having a number of other usability issues. I understand your complaints about Wayland but there has just never been any API for this that I've seen on any Linux window system that is actually secure, it just doesn't exist right now. If a secure API is ever implemented, it will probably be made to work with Wayland somehow.
The point is that Wayland architecture is designed to discourage such API, secure or not (I'll also have to check, but AFAIK Wayland went with even less security support in protocol than X11[1] - not XFree/XOrg - so retrofitting is even harder). Same with accessibility et al.
Honestly, Wayland by design feels like MVP that forgot that outside certain limited systems they are missing a lot of "filler" APIs, and somehow assumed it would magically happen by itself. Unfortunately there's no DCOM on Linux in practice, and D-Bus is much more annoying to program against, so the expected "do it in D-Bus" never materialized (and was supposed to cover even things like copy-paste in the original discussions).
[1] X11 servers from vendors other than XFree/XOrg had things like advanced access controls over what applications could do, some integrated with OS-wide Mandatory Access Controls. There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
Honestly, Wayland by design feels like MVP that forgot that outside certain limited systems they are missing a lot of "filler" APIs, and somehow assumed it would magically happen by itself. Unfortunately there's no DCOM on Linux in practice, and D-Bus is much more annoying to program against, so the expected "do it in D-Bus" never materialized (and was supposed to cover even things like copy-paste in the original discussions).
[1] X11 servers from vendors other than XFree/XOrg had things like advanced access controls over what applications could do, some integrated with OS-wide Mandatory Access Controls. There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
FWIW I think the goal has been to put security in some other layer that's more appropriate. You can add those type of APIs to Wayland but you'd have to also implement a security mechanism, which is non-trivial. D-Bus can be the most secure option for some things but not here, there might have been a plan to put the clipboard in D-Bus but I believe that got scrapped because it was found to be less secure; Wayland implementations are supposed to validate access to the clipboard based on the most recent input event, to prevent background applications from snooping on the clipboard.
Personally for me I do find D-Bus to be easier to program than Wayland though, the libraries for it are a lot more mature. You might want to try something like pydbus or systemd's sd_bus, or the Rust library zbus. Those are some of the better implementations I've seen.
X11's security mechanisms were never really complete, I don't know of any distribution that actually uses those Mandatory Access Control schemes. Distributions that focus around X security (e.g. Qubes) all seem to use X sandboxing now which should work better than MAC-based security but is quite complicated to set up and still not practical for most other distributions to use. I remember seeing some MAC-based proposals for Wayland but they never caught on because the focus there has also moved to sandboxing.
>There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
AFAIK there is no special part of the protocol for this and this was never really a good solution. It's just done using an ordinary keyboard grab, which are mostly considered an insecure API that does nothing in practice because all the other X security schemes will try to disable or restrict grabs for security reasons.
Personally for me I do find D-Bus to be easier to program than Wayland though, the libraries for it are a lot more mature. You might want to try something like pydbus or systemd's sd_bus, or the Rust library zbus. Those are some of the better implementations I've seen.
X11's security mechanisms were never really complete, I don't know of any distribution that actually uses those Mandatory Access Control schemes. Distributions that focus around X security (e.g. Qubes) all seem to use X sandboxing now which should work better than MAC-based security but is quite complicated to set up and still not practical for most other distributions to use. I remember seeing some MAC-based proposals for Wayland but they never caught on because the focus there has also moved to sandboxing.
>There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
AFAIK there is no special part of the protocol for this and this was never really a good solution. It's just done using an ordinary keyboard grab, which are mostly considered an insecure API that does nothing in practice because all the other X security schemes will try to disable or restrict grabs for security reasons.
Ah yes, security through magic fairy. To their credit, at least they went with "you can't break security through nonexistant feature", except a lot of those features tend to be critical for open desktop.
D-Bus is still way more problematic to work with than DCOM. Even on the operation model (something that generic libraries will always have hard time papering over).
As for the X11 extensions - no Linux distro (at least on open market). Because XFree86/X.Org != X11. In fact, XFree86 was essentially lowest common denominator, using with little change a design that wasn't specially good back in 1992. Even if glamor helped some of it, it was more a bandaid than rearchitecting the server (which could have been done without changing protocol).
D-Bus is still way more problematic to work with than DCOM. Even on the operation model (something that generic libraries will always have hard time papering over).
As for the X11 extensions - no Linux distro (at least on open market). Because XFree86/X.Org != X11. In fact, XFree86 was essentially lowest common denominator, using with little change a design that wasn't specially good back in 1992. Even if glamor helped some of it, it was more a bandaid than rearchitecting the server (which could have been done without changing protocol).
> the whole system is incapable of providing such feature in pluggable way
No, the system is perfectly capable, it's just hard to get all compositor authors to agree on a common protocol (and to agree that it's necessary in the first place). Big DEs especially prioritize regular-user usability features (e.g. currently lots of work on IMEs) rather than fancy nerd customizations that don't always need to be a common external program that works with all compositors (is it really a problem to write a plugin for your DE specifically? No!).
No, the system is perfectly capable, it's just hard to get all compositor authors to agree on a common protocol (and to agree that it's necessary in the first place). Big DEs especially prioritize regular-user usability features (e.g. currently lots of work on IMEs) rather than fancy nerd customizations that don't always need to be a common external program that works with all compositors (is it really a problem to write a plugin for your DE specifically? No!).
No, the system is designed for centralizing everything in one process, and biggest pusher is uninterested in cooperating with anyone else.
And ability to have global hotkeys is not fancy nerd customization. Writing a plugin is also a much more harrowing experience when any bug might take down your entire graphics stack due to above mentioned centralization by design.
And ability to have global hotkeys is not fancy nerd customization. Writing a plugin is also a much more harrowing experience when any bug might take down your entire graphics stack due to above mentioned centralization by design.
What did you contribute to X?
I kind of trust Daniel Stone way more that some rando from internet? https://www.phoronix.com/scan.php?page=search&q=Daniel+Stone
I kind of trust Daniel Stone way more that some rando from internet? https://www.phoronix.com/scan.php?page=search&q=Daniel+Stone
Who uses just one computer? When everything targets a web UI because it’s the only choice on the network, do I still need a compositor to host a browser and nothing else?
FWIW the Xorg already has the functionality to isolate clients from each other, but it is underdocumented and not that easy to set up - see xauth as a starting point.
The limitations that are there are very minor and if someone cared they could be completely eliminated. As you wrote, Xorg is opensource - which also means that these limitations exist since there wasn't much of an interest towards addressing them.
Though there is also the bureaucracy aspect - in recent years i've been trying to provide fixes, improvements, etc on various open source projects i'm using and i've noticed that the more involvement there is by companies in a project, especially among maintainers, the more bureaucracy and harder it is to get things merged to the point where whenever i see an issue with something that has at least one bigger company behind it, my first instinct is to make my own fork, fix it there and leave it at that. Or not bother. Projects that are primarily run by volunteers tend to be way easier to get involved with.
The limitations that are there are very minor and if someone cared they could be completely eliminated. As you wrote, Xorg is opensource - which also means that these limitations exist since there wasn't much of an interest towards addressing them.
Though there is also the bureaucracy aspect - in recent years i've been trying to provide fixes, improvements, etc on various open source projects i'm using and i've noticed that the more involvement there is by companies in a project, especially among maintainers, the more bureaucracy and harder it is to get things merged to the point where whenever i see an issue with something that has at least one bigger company behind it, my first instinct is to make my own fork, fix it there and leave it at that. Or not bother. Projects that are primarily run by volunteers tend to be way easier to get involved with.
There is the X11 security extension but as far as I understand this only isolates X clients into two domains. Untrusted apps cannot keylog / screenshot your trusted applications, but every untrusted client can keylog / screenshot any other untrusted client. If every client is untrusted this is pretty much useless. If there is a method other than running a dummy xorg server for each application I am very interested.
I haven't tried it for more than one client to make sure and i think there are still some things untrusted clients can do, but basically my point is that the functionality for Xorg to treat clients differently is there. I do not think modifying the code to have each untrusted client in its own domain would be too complex if someone cared to look into it (as well as adding further restrictions if necessary) - the main issue here seems to be that nobody really cared much about changing Xorg towards doing that.
But there isn't really any core limitation of how X works that couldn't make it so that, e.g., some "privileged" applications (like the window manager) can decide what other less privileged clients can see and even create "domains" on the fly (as far as the applications are concerned it'd be like clients connecting/disconnecting from the server) for applications to see each other if needed. It could be possible if there were people interested in it (and interested enough to implement it, of course :-P).
But there isn't really any core limitation of how X works that couldn't make it so that, e.g., some "privileged" applications (like the window manager) can decide what other less privileged clients can see and even create "domains" on the fly (as far as the applications are concerned it'd be like clients connecting/disconnecting from the server) for applications to see each other if needed. It could be possible if there were people interested in it (and interested enough to implement it, of course :-P).
This comment isn't really correct all, it's not possible to do that with the architecture of X. The best you can get is XSecurity and its related extensions, anything more than that is going to break the protocol. There is quite a good reason that Qubes has not even tried to get X to do this. The main issues are that the protocol is sequential and you can't reorder requests which makes modern polkit-style mechanisms practically infeasible, and also you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib because it is complicated and badly implemented. More about that here: https://news.ycombinator.com/item?id=21267275
BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
> This comment isn't really correct all, it's not possible to do that with the architecture of X.
Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and...
> you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib
...any errors would be the same as if the other clients didn't exist and handled the same way.
Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.
Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and...
> you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib
...any errors would be the same as if the other clients didn't exist and handled the same way.
Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.
His blog is really great but last time I didn't find a way to post a comment or to contact the author. Do somebody knows better?
I usually notice if my blog gets on Hacker News fairly soon, so I'll see any comments posted here.
I prefer not to use email for most things because then the reply only benefits one person, whereas replies in a public forum can be read by others and get indexed by search engines.
I've been thinking about creating a Matrix room for each blog post as a discussion forum, but so far most posts have ended up on other discussion sites anyway.
I prefer not to use email for most things because then the reply only benefits one person, whereas replies in a public forum can be read by others and get indexed by search engines.
I've been thinking about creating a Matrix room for each blog post as a discussion forum, but so far most posts have ended up on other discussion sites anyway.
Regarding the performances issues that you had with Qubes: I once disabled power management on one of my laptop and it moves Qubes from barely usable to usable.
Still close to unusable: Web conferences in the browser (webex for example).
Still close to unusable: Web conferences in the browser (webex for example).
I think that some blogs have email lists as discussion forum with each thread devoted to one post, but I can't come up with examples right now. If the email list archive is public, it might be the perfect solution.
The author links to his github account, you should be able to extract _some_ kind of email address from the git commit log.
To me it seems that the author doesn't list contact details on purpose. There's an extensive "about me" section without any contact information, so I think the author might wish not to be contacted.
Edit: actually, his Gmail is in one of the screenshots in this article.
To me it seems that the author doesn't list contact details on purpose. There's an extensive "about me" section without any contact information, so I think the author might wish not to be contacted.
Edit: actually, his Gmail is in one of the screenshots in this article.
Very good article,
the linked code about vim is incredible tho (and not the good kind of it), I have actually spent a good part of my evening trying to understand how they end up with that implementation (I do have the same kind of spaghetti code and wonder the same about my code) :
https://github.com/vim/vim/blob/9cd063e3195a4c250c8016fa3409...
the linked code about vim is incredible tho (and not the good kind of it), I have actually spent a good part of my evening trying to understand how they end up with that implementation (I do have the same kind of spaghetti code and wonder the same about my code) :
https://github.com/vim/vim/blob/9cd063e3195a4c250c8016fa3409...
Interesting. WSLG seems to do this as well, bundling Xwayland, Pulse Audio, and Weston into a single separate VM that serves all the user-installed WSL distros on a box. https://devblogs.microsoft.com/commandline/wp-content/upload...
[Edit: I found the blog entry from March that mentions SpectrumOS.]
Maybe you should know about the project SpectrumOS, which seems to have extremely similar goals to yours.
https://spectrum-os.org/
I think instead of running persistent VMs for different roles, it spins up VMs very quickly to run individual apps in.
Maybe you should know about the project SpectrumOS, which seems to have extremely similar goals to yours.
https://spectrum-os.org/
I think instead of running persistent VMs for different roles, it spins up VMs very quickly to run individual apps in.
https://www.qubes-os.org/news/