Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Note that this is not Blink the rendering engine that powers Chromium and related browsers, but https://github.com/jart/blink, “a virtual machine that runs x86-64-linux programs on different operating systems and hardware architectures”.

Where this talks of running GUI programs, I presume it means that the VM can act as an X client. You would thus still need an X server. I don’t know what may exist along those lines for the web. As for native/desktop hosts, well, I hope you weren’t ever trying to use emulation as any form of security, because the likes of Xorg really aren’t designed for that use case.

View on HN

> the likes of Xorg really aren’t designed for that use case.

Bullshit. Would be nice if people were to stop spreading these outright lies.

Straight from the horse's mouth:

https://www.x.org/wiki/Development/X12/

> In short, X11 was designed for a different era of computing.

> This is not to say that there's an X12 project. There isn't. But if one day there is...

> Systems need to be secure. X12 needs to be designed with security in mind.

Do you think the Xorg devs are spreading lies about Xorg?

> Do you think the Xorg devs are spreading lies about Xorg?

Some are, yes, this is incontrovertibly true. But this one? You should hit the "history" button that's in the corner of every wiki. That page hasn't been edited at all since 2013, imported from some other document written I don't know when, and literally the only thing it actually says about security is that "needs to be designed with security in mind".

What does that mean? What specific shortcomings have they identified?

The fact that any Xorg client can become a key logger without any user input or authentication is a pretty big security hole imo.

By design Xorg has no isolation between clients so they can all read each others input, control others windows, and inject keystrokes into other applications. That’s unacceptable in the modern age and makes any attempt at sandboxing or separation of privileges for GUI applications completely pointless.

> The fact that any Xorg client can become a key logger without any user input or authentication is a pretty big security hole imo.

This "hole" doesn't exist. For an X client to capture input, it must be authenticated by either the unix user permission or by an access control list (where the default is to deny). Individual clients can also be marked untrusted which sandboxes them to some extent (though not as much as using a separate X server of course).

I'll grant that in practice, most the time these restrictions are very lax... in part because they can break some applications. But at the same time, in practice, it doesn't seem to matter that much since either you're running things you trust anyway or if a malicious application has access to your X connection they also have access to all your other files so you're in trouble anyway.

Simple solution: isolate, by running 1 X server per client (or set of clients if you want gimp and krita in the same sandbox)

Is there any tutorials/examples of how to do this?

Apologies for not answering your question directly, but I'm pretty sure this is what XWayland does to allow for compatibility of X apps ontop of wayland.

I imagine it's mostly the issue related to applications having too much access to thinks like the keyboard and other windows without a permission system? That's a large part of what makes Wayland different from X11.

I’m curious how you think it an outright lie. I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards.

> I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards.

This is not true! Both the protocol and the implementation allow for significant separation of server permissions (for example, notice the difference between ssh -X and ssh -Y), and the peer-to-peer nature of things like clipboard means it is quite easy to deny requests on an application level if they're written for it.

XTerm has basic keyboard locking support.

It runs the X server in the VM.

If the X server were running in the VM, how would it display things, or get keyboard and mouse input? You’d need to provide emulated hardware devices, which could be something like /dev/fb0 for output and /dev/input/ devices for keyboard and mouse. All that is a very much larger undertaking, and probably a good deal less useful in general. The likes of X are a much more suitable abstraction.

The change here is implementing sendmsg and recvmsg: socket communications, implying communicating with something outside the VM, which in the context of GUI stuff almost certainly means an X server from outside.

Not in this demo. It probably could though.

There's a X with sixel support: https://github.com/saitoha/xserver-sixel

I played with this before, and I could use X11 within a mlterm terminal.

I should try to recompile it with cosmopolitan to have a single X server binary both for Windows and Linux

That's amazing!

And this is why I'm so interested in Sixel support for the Windows Terminal (https://github.com/microsoft/Terminal/issues/448)

With that and a X server using sixels, there would no longer be a need for something as complex as wslg for most apps: you could just export DISPLAY in your .bashrc, then use one Windows Terminal tab to start X apps, and the other one to display/interact with them.

Reply on news.ycombinator.com