Feat: Disabling certain (potentially risky) protocols

[cyrneko]

Niri supports protocols such as wlr-screencopy which may be potentially risky

This isnt a problem from within sandboxed applications where the sandbox uses security-context-v1 because Niri doesn't allow those to use this protocol

However clients running on the host can still use this freely.

Whilst it isnt a huge security consideration, as there's plenty other ways to grab this data on the host, I also see no reason to leave it enabled when it is unused and it makes for a slight attack surface reduction as that protocol could then no longer be used.

So, the proposal is making potentially "risky" protocols optional, i.e allowing the user to disable them in the config. Right now this would limit itself to wlr-screencopy as I do not know of other protocols which may be considered "risky"

In the future, maybe this could also be scoped down to certain programs having access to a protocol, but actually implementing this might be hard as there's no way I know of a client can prove e.g it's truly what it says it is.

in essence, this github-discussion serves for discussing how/if this would be implemented and what the configuration for this would look like

[YaLTeR]

My niri threat model assumes that the host is trusted. This is more or less the only reasonable assumption to make, because anything running on the host can trivially e.g. load an arbitrary .so into any process by setting LD_PRELOAD in your ~/.bashrc or something like that. This is also why all niri IPC commands are trusted (you can do the IPC equivalent of niri msg action spawn of any process for example).

allowing the user to disable them in the config

Just like editing ~/.bashrc to inject arbitrary code into all processes, anything running on the host can also edit the niri config to disable this.

[cyrneko]

That does make a lot of sense, thanks for the input!