Wayland Clients Can Now Survive Qt Wayland Crashes / Compositor Restarts

[gotar]

Every attack I have seen put forwards against Wayland compositor does not work with selinux setup correctly.

I haven't seen any SELinux setup that doesn't break some legit application.

[Sorry, couldn't resist].

[gotar]

This arguement here is basically the arguement that our cars and houses should not have any locks.

In Wayland there are no doors. Neither back-doors, nor front-doors.

[gotar]

dbus interfaces feature of dbus-broker is to allow all dbus requests to be filtered by the selinux rules.

URL? please. Can't find anything on that subject.

[oiaohm]

I haven't seen any SELinux setup that doesn't break some legit application. [Sorry, couldn't resist].

That the thing SELinux and other mandatory access control options under Linux are quite vengeful things. More things application does the more likely it will do something mandatory access control will take offense at and terminate it.

In Wayland there are no doors. Neither back-doors, nor front-doors.

Mandatory access control where ever you put a door expect that a trigger happy security guard is going to be placed there who is going to kill a few parties by mistake and due to the weapon they are packing possible flatten the door and the building connected. So limited doors wayland protocol limits the risk of being terminated by selinux trigger happy security guard. Wayland does have some doors or graphics and input could not pass along it.

URL? please. Can't find anything on that subject.

https://subscription.packtpub.com/book/networking-and-servers/9781783989669/10/ch10lvl1sec88/controlling-d-bus-message-flows

This is setting up selinux rules for dbus.

https://github.com/bus1/dbus-broker/wiki/Deviations/ I had forgot a bit.

Reply Policies: While the reference-implementation supports applying D-Bus policies to method-returns, as well as filtering on whether a reply is expected or not, dbus-broker does not support this. Specifically, dbus-broker only allows expected replies, and those are allowed unconditionally. Unexpected-replies and Reply-filtering have no known users (nor use-cases), hence support has been dropped. Note that in the case of SELinux, this means that it is sufficient to grant access in one direction (to send a method call), and the reverse (to send the reply) is implicit. This avoids overly broad permissions.

dbus-broker only filters applications doing request to dbus service not dbus service reply messages. dbus-daemon has filtering in both directions request and replys yes this is kind of stupid allowing a request and when dbus-service replys have selinux terminate it so application can do request after request causing a poor dbus service to be repeatedly nuked.

Yes selinux seeing something attempt request on dbus it should not can be instant termination.

Yes polkit policy and selinux policy is at play when you use a dbus connection. Yes processing both of these policys has overhead.

Living with Mandatory access control causes a different mindset of lets try to obey the old unix rule of do one thing well where possible so that when the Mandatory access control takes offense that the damage is hopefully limited. This explains why the core Wayland developers don't want to keep on adding features.

Yes mandatory access control can be very much like himars being fired at building(being application) as anti-burglar solution. Yes it anti-burglar but it also anti-building. Multi process solution is having more building to be destroyed to hopefully reduce the risk of it being anything critical and the cost of the damage.

Yes putting everything in one item is asking for it on systems with Mandatory Access Controls like selinux.

[gotar]

Yes selinux seeing something attempt request on dbus it should not can be instant termination.

Yes polkit policy and selinux policy is at play when you use a dbus connection. Yes processing both of these policys has overhead.

This is kind of thing I was doing last week. The task:
- having restricted root shell (CAP_KILL CAP_NET_ADMIN CAP_SETGID CAP_SYS_BOOT CAP_SYSLOG CAP_NET_RAW, SECBIT_KEEP_CAPS_LOCKED SECBIT_NO_SETUID_FIXUP_LOCKED SECBIT_NOROOT_LOCKED SECBIT_NOROOT, no new privileges + seccomp filtering of device access, before anyone responds with vi /dev/sda),
- prevent from calling privileged dbus method calls globally.

The problems:
- there is no socket option to return capabilities (so I could check for CAP_SYS_ADMIN in specific rules),
- there is no system-wide filter to strip supplementary groups (wheel in this case), probably due to this commonly unknown feature [and other descriptions of CVE-2014-8989] (except for userns, but I simply want to restrict the current account in current system),
- PolKit AdminRules are capable of performing user, group and netgroup only,
- there is no PolKit syntax to quietly deny AdminRule (empty result skips to next rule),
+ funny thing - I've just realized that as a consequence of 3 above there's no supplementary group-based blacklisting, while this could be implemented without kdbus...
- PolKit recognizes only admins and owners of the session.
Therefore you can only choose whether to ask for user or admin credentials.

Conclustions:
- you cannot easily restrict any account globally from the PolKit/dbus perspective,
- you cannot use fine-grained rules for any specific method.

Therefore entire dbus communication is DAC-only.


Request filtering in dbus doesn't help much - I don't know a priori the full set of privileged methods to filter out. I need to filter them in transit, just as they perform check for administrator (or session owner), so SELinux doesn't help either. And definitely don't want to kill the requester, simply deny the action.

This explains why the core Wayland developers don't want to keep on adding features.

It's not about adding features itself, it's about missing security model (libwsm) while repeating the "more secure" misinformation. This is manipulation, as it implies there is some actual "security" built in, while the only true meaning of this is "less insecure than backdoored-by-design X11".


Most burglars use doors, but removing the doors won't stop any burglars - they would use windows instead.
You gain nothing sacrificing your own convenience.

The proper solution is to built in and keep improving the locks.

[oiaohm]

This is kind of thing I was doing last week. The task:
- having restricted root shell (CAP_KILL CAP_NET_ADMIN CAP_SETGID CAP_SYS_BOOT CAP_SYSLOG CAP_NET_RAW, SECBIT_KEEP_CAPS_LOCKED SECBIT_NO_SETUID_FIXUP_LOCKED SECBIT_NOROOT_LOCKED SECBIT_NOROOT, no new privileges + seccomp filtering of device access, before anyone responds with vi /dev/sda),
- prevent from calling privileged dbus method calls globally.

The problems:
- there is no socket option to return capabilities (so I could check for CAP_SYS_ADMIN in specific rules),
- there is no system-wide filter to strip supplementary groups (wheel in this case), probably due to this commonly unknown feature [and other descriptions of CVE-2014-8989] (except for userns, but I simply want to restrict the current account in current system),
- PolKit AdminRules are capable of performing user, group and netgroup only,
- there is no PolKit syntax to quietly deny AdminRule (empty result skips to next rule),
+ funny thing - I've just realized that as a consequence of 3 above there's no supplementary group-based blacklisting, while this could be implemented without kdbus...
- PolKit recognizes only admins and owners of the session.
Therefore you can only choose whether to ask for user or admin credentials.

Conclustions:
- you cannot easily restrict any account globally from the PolKit/dbus perspective,
- you cannot use fine-grained rules for any specific method.

Therefore entire dbus communication is DAC-only.

All this and you miss the basic thing I stated before.

Selinux filters dbus by dbus service. Yes this is not fine-grained this is broader grain since it per dbus service. Now the service is privilege being able to query that service you might be able to find a buffer overflow.

dbus communication is not DAC only. LSM extra information travels with sockets.

https://www.usenix.org/legacy/publications/library/proceedings/usenix01/freenix01/full_papers/loscocco/loscocco_html/node10.html

https://bugzilla.redhat.com/show_bug.cgi?id=1861054

selinux and equal LSM can have restricted off all that stuff as well.

Request filtering in dbus doesn't help much - I don't know a priori the full set of privileged methods to filter out. I need to filter them in transit, just as they perform check for administrator (or session owner), so SELinux doesn't help either. And definitely don't want to kill the requester, simply deny the action.

The reality here as long as you are not attempting to be absolute fine grained so per dbus service/process is good enough and you are willing to put up with instant termination selinux does everything you want. Including being able to kill off the CAPs.

By the way all the problems you listed with polkit if you were to put a security system into wayland compositors they would have be solved as well. Polkit would still need to be fixed because we are still going to be using dbus right.

From memory polkit is is pre pidfd work and has not been updated to take advantage of it..

[Weasel]

Most burglars use doors, but removing the doors won't stop any burglars - they would use windows instead.
You gain nothing sacrificing your own convenience.

The proper solution is to built in and keep improving the locks.

Thanks for the perfect analogy. I hope you don't mind I'm gonna use it in the future.

[carewolf]

Copy paste mess explains why above happened. Wayland protocol from first version copy/paste worked. Xwayland copy paste X11 to X11 application worked from day one.

No. Wayland didn't have copy/paste until like 5-7 years after it was launched. It was "up to the compositor"... And only some 11 years after invention did it add the select-buffer that X11 had.

[oiaohm]

No. Wayland didn't have copy/paste until like 5-7 years after it was launched. It was "up to the compositor"... And only some 11 years after invention did it add the select-buffer that X11 had.

https://wayland.freedesktop.org/docs...-wl_data_offer this is the current copy paste interface of Wayland
https://cgit.freedesktop.org/wayland/wayland/commit/protocol/wayland.xml?id=eae3bcb4ccb80ef1c4dcd2f71987c1187ae b9e73 Yes 2011-11-15.

selection version of copy paste that was removed from the protocol at 2011-11-15
https://cgit.freedesktop.org/wayland/wayland/commit/protocol/wayland.xml?id=ae6c8a6d731b3543bdea0f40757206908d7 5d6f4 2011-01-19

If you measure from start of full time active development that is 2010-10-12 then it 3 months in for first copy paste to appear 1 year and month for what we use today on Wayland. If you measure from 2008 its 3 years to first copy paste 4 years to the Wayland current version of copy paste.

Yes it was in wayland 1.0 time frame that had copy paste. 5-7 years claim is absolutely wrong that pushing into Wayland 1.1 time frame being 2013-04-18 when 1.1 was released. My statement about first version was kind of right I was thinking Wayland 1.0 stuff.

The first copy I saw of wayland protocol was 2011. 11 years later is sorting out the mess of how to map X11 copy paste to Wayland copy paste.

First version of wayland copy paste called selection comes before wayland can do fullscreen windows(2011-01-28). Without fullscreen windows wayland was not suitable of kiosks. Prototypes on kiosks come after copy paste.

Yes fun that the wayland developer called the first implementation of copy paste selection in the Wayland protocol not copy paste right.

[ferrellsl]

Were you using X around the millennium (when it was as old as Wayland is now)?

I was, it wasn't nearly as mature as Wayland is now.

Maturity and age are two entirely different things. You're confusing the two. And yes, I was using X even before the millennium.