expand namespace

[squishypinkelephant]

expand namespace capabilities to handle (all?) of the major extensions modify checks to enable functionality of a window manager running in the root namespace add in checks for superpower to function properly
try to make the allowMouseMotion permission consistent add globalkeyboard as a specific permission for keypress events sent to root namespace add randr and render permission settings

this should work for better isolation while also allowing everything to "just work" inside a WM

tested inside Xephyr using icewm. some programs ask for absurd things and will make minimizing resource access tricky
regardless, running a window manger in the root namespace, I can open firefix, gimp, krita, dolphin in independent namespaces. xkbcat and other still denied global keyboard by new keyword.

it's a little crude and thrown together but it satisfies what i think is a perfect start for further improvements.

[squishypinkelephant]

testing with xfce4 now, as things are now namespace functions as advertised. demo software from #1627 denied when running in non-root namespace.

Any criticism welcome.

[callmetango]

Thank you for your contribution! I converted this pull request to a draft because of:

it's a little crude and thrown together

This is not intended to discourage it, but rather to point out that some improvements and discussion are needed.

[squishypinkelephant]

Of course, no complaints here. I'd prefer things be more refined as well.
In terms of total goals: getting "any" software running and functional in a non-root namespace while maintaining the original concepts: no access between namespaces, selective access to root resources. With as much as I've put in this far, I would say the goal is met 70%.

In terms of what I'm still working on:
As some already know, protecting the screen is all or nothing via mit-shm (and composite). I'm debating on just combining the two into just a simple "screen" access and avoiding any obscene security theater, though the simple separate access could work out.
There's various random requests from screen capture tools to capture the mouse pointer and those requests will be either simply allowed (if they don't give away location hints like pulling only the pointer image) or restricted to mouse-motion.
Root namespace atoms are requested seemingly randomly by various programs but exposing those is simple.
As a stretch goal, Obs runs some checks through xcb instead of xlib and I'd like to get it working from inside a non-root namespace. I can get it most of the way by exposing shm and composite but the checks it runs don't trigger any alerts and the xcomposite extension gets disabled.
A nice to have would be a toggle and default quiet logs because Firefox at least loves to spam the absolute hell out of junk requests. And this is causing obvious lagging.

[callmetango]

Just FYI because the discussion more or less augments your idea: Ideas on XNamespace. · X11Libre · Discussion #440

[stefan11111]

@metux Is there some docs/spec for the namespace extension? I have no idea how it is supposed to be used, or what an X client should do to use it.

[metux]

@metux Is there some docs/spec for the namespace extension? I have no idea how it is supposed to be used, or what an X client should do to use it.

not yet, but we IMHO have some piece of config documentation.

note there's no X11 protocol extension yet (but planned for the future) - just static configuration.

[squishypinkelephant]

Pushing my own goalpost along, I took the ideas from that discussion and started work on them.
I've been working on moving the logic for adding/modifying/deleting namespaces into independent functions to make adding a protocol extension seamless. Moving clients to a new namespace is already a function so no work needed there.
For the most part I've solved adding a new namespace and deleting an unused namespace at runtime, all I'm missing is freeing the fake root screen that gets made, then it's "complete".
Along with modifying the logic to actually check for access instead of dumping new connections to the anon namespace and letting anything connect.

[squishypinkelephant]

@metux Is there some docs/spec for the namespace extension? I have no idea how it is supposed to be used, or what an X client should do to use it.

I'll put some work into this as well. There's quite a bit of misinfo around how it works because of the limited existing documentation so better documentation is a good idea regardless.

[squishypinkelephant]

The (new namespace per client connection) is currently highly experimental. And I'm only really exploring it for my own amusement. I'd be fine dropping the idea entirely because of the technical limitations of practically implementing it server-side.

Considering how client connections work out, there's no "grouping" (unless the env is set with the cookie) for child processes should the (new namespace per client connection) setting be set. The server can't currently, won't without rework, and arguable shouldn't ever be able to do that.
Browsers are especially notorious for this since they LOVE to spawn 8 or so child processes that all act as independent client connections but shutting that noise up by passing a cookie works out.

Aside from that, there's still solving the entire "where do we dump unauthorized connections in the first place" problem. Anon namespace works and will keep them isolated but ideally the server just denies the unauthorized connections.

[metux]

some programs ask for absurd things and will make minimizing resource access tricky regardless, running a window manger in the root namespace,

Window managers probably should always run in root NS, since they usually need a huge amount of control.
In the longer run, WMs should also become NS-aware, eg. showing which NS some client is running in, etc.

xkbcat and other still denied global keyboard by new keyword.

This is one of the quite low level tools that probably belong into root NS. Same for various hotkey manager tools.

[metux]

Of course, no complaints here. I'd prefer things be more refined as well. In terms of total goals: getting "any" software running and functional in a non-root namespace while maintaining the original concepts: no access between namespaces, selective access to root resources. With as much as I've put in this far, I would say the goal is met 70%.

Well, 100% would be somewhat self-contradicting, since some clients are supposed to have control over others or global aspects of the Xserver, e.g window managers, input or output configuration tools, hotkey managers, ....
Perhaps we should instead talk about "user applications" - those clients that people use for some actual work (while putting the others into the "infrastructure" bin).

As some already know, protecting the screen is all or nothing via mit-shm (and composite).

Indeed. These things just haven't been fully finished yet.
Composite extension isn't supposed to be used by unprivileged clients (that would be a contradiction in itself), just by the privileged window manager / compositor (root NS).

There's various random requests from screen capture tools to capture the mouse pointer and those requests will be either simply allowed (if they don't give away location hints like pulling only the pointer image) or restricted to mouse-motion.

Those tools naturally belong into root / privileged NS, because it's their duty to touch privileged things.
A tricky question is how exactly do deal with browsers that wanna do screen sharing.

As a stretch goal, Obs runs some checks through xcb instead of xlib and I'd like to get it working from inside a non-root namespace. I can get it most of the way by exposing shm and composite but the checks it runs don't trigger any alerts and the xcomposite extension gets disabled.

What exactly does OBS do with xcomposite ?

A nice to have would be a toggle and default quiet logs because Firefox at least loves to spam the absolute hell out of junk requests. And this is causing obvious lagging.

Yes, logging indeed needs improvements. For now it's pretty verbose in order to assist development as well as config/policy tuning.

[metux]

I've been working on moving the logic for adding/modifying/deleting namespaces into independent functions to make adding a protocol extension seamless.

Deleting namespaces is still an open topic - how shall we deal with existing clients ?
Just kill them off ? Refuse deletion of non-empty namespaces ?

[squishypinkelephant]

Deleting namespaces is still an open topic - how shall we deal with existing clients ? Just kill them off ? Refuse deletion of non-empty namespaces ?

The latter is what I have currently since there's nothing else but a ref counter tracking connections. I toyed with the idea of actually tracking clients by their clientpriv before I ever tried deleting namespaces but hadn't committed to it yet since I didn't know what should be done with existing clients. I can a imagine lot of crashing if the permissions aren't similar while moving namespace to namespace to begin with, outside of only ever checking if the namespace is empty for deletion.

What exactly does OBS do with xcomposite ?

It (and other screen share software including browsers) use it for sharing 'only' a single window. I toyed around with rerouting access to the window owned by the call but it's a pointless endeavor. there's no reason to make it that complicated.

Composite extension isn't supposed to be used by unprivileged clients (that would be a contradiction in itself), just by the privileged window manager / compositor (root NS).

For practicality sake should I just lump it with SMH using allowScreen then? I only kept them seperate for more grainular control.

Well, 100% would be somewhat self-contradicting

Naturally. I wouldn't expect it being any other way, and that's how I've been testing everything - by running 'privileged' clients like the WM in the root namespace, I moreso meant "user applications"