GNOME Shell & Mutter Complete Their Migration Away From GTK3

[gotar]

dbus-broker does not have the racy problem of dbus-deamon.

The races are with PIDs, not dbus implementation.

Notice you only looked at DAC. You have completely forgot MAC.

Because struct ucred contains only 3 __u32 values and that's basically the end of the story.

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

Doesn't matter, I'm talking about calling privileged functions over dbus (PolKit and friends).

The claim of no counter measure is not true. Correct selinux policy or other equal Linux LSM Mac policy and the attacks against Wayland compositors are dead in the water.

You can say the same for X11 - correct SELinux policy with X-SECURITY and the attacks are mitigated.

Also https://bugs.freedesktop.org/show_bug.cgi?id=84817 Wayland protocol design does not forbid Wayland compositor running as a different user to the applications. Just DAC on the Wayland socket has to be setup to allow it.

Doesn't Wayland use abstract socket? Anyway - wayland-server.c confirms that only ucred is checked, no capabilities:
getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &client->ucred, &len)
therefore I guess such scheme would defeat any user isolation...

But to be honest I'm not quite sure now...

Root-ful Xserver is always more insecure because any flaw in Xserver that allows code to turn allows root privillage operations.

No, it doesn't (always). First of all - you can run capability-constrained X.
Second - it doesn't need to be the actual root (that was just my dumb example), just some dynamic user given the seat permissions after registering the session (e.g. pam_systemd).
Third - you need to exploit not only the app, but also the Xserver, just to get to the 'nobody' user.

gotar something to remember selinux and other solutions mac policies can apply rules that even run as root you cannot override.

I use seccomp sandboxing on a daily basis and believe me - it's not that easy to constrain root in real systems.

Discretionary access control (DAC) is weaker by massive amount than Mandatory Access Control and Cgroups/namespaces. The idea of security by run as a different user is from a time when systems only had DAC when MAC and Cgroups/namespaces did not exist.

Namespacing doesn't exhaust security. It helps as a last resort safety net, but doesn't prevent basically anything in principle.

Sandboxing is not the job of the display server. Sandboxing is the job of the MAC or whatever running applications. MAC at kernel level already provide the tools not to trust any application user starts.

A few lines below you stated:

KDE is moving in the direction of cgroup/namespace sandboxing

.

Apparently KDE guys see the problem.

Do you really expect people to create SELinux policies for some untrusted code before they execute it? I'm not talking about running Firefox securely (with their own sandboxing, AppArmor profiles or provided SELinux labels).

I'm talking about running some random flatpak from the web.

What I would expect is the enforced by the standard scheme that makes every Wayland application to define it's own properties that could be used for sandboxing (something like: flatpak sandboxes, Ad-roid app permissions etc.)

Currently we have PolKit with it's lame rules (their potential looks like something designed in 1990s).

Yes lots of people fail to notice that a Linux kernel MAC can block LD_PRELOAD or running ld.so/ld-linux.so with different options to alter application behavior.

Why even bother with LD_PRELOAD, when I can run my own display server? Just do me a favour and don't mention noexec - I want to run some random code from the net in securish fashion.

[oiaohm]

The races are with PIDs, not dbus implementation.

filehandling wrapping like PIDFD and socket filehandle wrapper remove these races. So its implementation.

https://github.com/bus1/dbus-broker/wiki/Deviations

Recursive FD Passing The linux kernel allows queuing a socket on itself. If a client passes a message with its own end of the Unix-Domain-Socket as payload, the message will keep the client alive, even if the original client exits and closes its FDs.

Application sent message on dbus its PID is not going to be recycled until no reply is going to be sent by the dbus-broker implementation. There is no PID race here. There is a PID race with dbus-deamon that is possible.

Because struct ucred contains only 3 __u32 values and that's basically the end of the story.

Its not end of story for dbus. The fun of having a filehandle of the connection to work with that dbus has.

You can say the same for X11 - correct SELinux policy with X-SECURITY and the attacks are mitigated.

No you have forgot to consider how SELinux mitigates problems. SELinux mitigates problems not by sorry you cannot do that but with you are now terminated.

Doesn't Wayland use abstract socket? Anyway - wayland-server.c confirms that only ucred is checked, no capabilities:
getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &client->ucred, &len)
therefore I guess such scheme would defeat any user isolation...

But to be honest I'm not quite sure now...

Get the file descriptor for the client is there for a reason. Read though wayland-server.c you can look up the ucred stuff but it does not do any validation on it at all.

Wayland by design is not a isolation system this explains why it functionality is so limited. There is no security framework here. You have Linux Security modules and namespace instead.

Apparently KDE guys see the problem.

KDE gets there sandboxing from using systemd as there desktop session management. Not the kwin Wayland compositor bit.

Wayland protocol is not a security protocol as you should have noticed by now. Wayland protocol by the design does the bare min in checks. Now trust wayland protocol to allow input capture/screen-capture you have to be insane its not designed for it. dbus is designed to check security.

Why even bother with LD_PRELOAD, when I can run my own display server? Just do me a favour and don't mention noexec - I want to run some random code from the net in securish fashion.

Selinux embedded the wayland socket is restricted. That means no you are not starting your own display server unless it has the right selinux credentials on it so it create/take over the Wayland socket if it does not have those credentials welcome to instant termination..

What I would expect is the enforced by the standard scheme that makes every Wayland application to define it's own properties that could be used for sandboxing (something like: flatpak sandboxes, Ad-roid app permissions etc.)

Why is the Wayland applications. KDE sandboxing come from the desktop session management the same session management they use under X11 and Wayland. Due to Wayland as you said not having doors its simpler to get this sandbox fully sealed up on Wayland than X11.

This is where it comes back to xdg-desktop-portals and desktop session management remember both of these things are generic be you running X11 or be you running Wayland.. Yes it would be good if Linux desktop environments could get on board with the same desktop session management.

There is a major attempt at feature creep here. Wayland protocol has nothing todo with sandboxing. Sandboxing on desktop is desktop session management problem wayland is not a desktop session management protocol.