probonopd / wayland-x11-compat-protocols

The missing Wayland protocols for features that are available in X11 (but are denied by the official Wayland protocols)
105 stars 3 forks source link

Shift Wayland Security to AppArmor by Creating a Bypass at the Compositor Level #23

Open GrootBlouNaai opened 2 months ago

GrootBlouNaai commented 2 months ago

The goal of these various protocols has been to make Wayland a true replacement for X11, avoiding the complications of D-Bus and Portals.

I propose refactoring the code of a simple compositor and shifting the security model to use AppArmor (or SELinux for rhel folks) instead. This approach aims to enhance security while maintaining the flexibility needed for Wayland to be an effective replacement for X11.

An fork of libwayland might be the best approach to shoehorn compatibility. My test Implementations at compositor level have all been flawed an resulting in many unexpected crashes (likely due to being self thought C, and absolutely useless at memory sanitising).

The general outline would be along the lines of:

void allow_system_wide_access(const char *app_id) {
    // Example: Modify the compositor's internal data structures to allow the specified app access to resources
    struct wl_client *client = find_client_by_app_id(app_id);
    if (client) {
        // Grant the client access to resources
        grant_client_access(client);
    }
}

struct wl_client *find_client_by_app_id(const char *app_id) {
    // Placeholder for the actual logic to find the client by app_id
    // This would involve iterating over the compositor's clients and checking their app_id
    return NULL; // Replace with actual implementation
}

void grant_client_access(struct wl_client *client) {
    // Placeholder for the actual logic to grant the client access to resources
    // This would involve modifying the compositor's internal state to allow the client access
}
probonopd commented 2 months ago

With AppArmor being optional, I'd agree. Personally I am not interested in this type of sandboxing at all since I don't run untrusted code on my machine.

alerikaisattera commented 1 month ago

While this seems good in theory, it has a problem of creating AppArmor dependency

probonopd commented 1 month ago

If the whole sandboxing is purely optional, then I'd not be opposed for the sandboxing to pull in some dependency. Might be AppArmor or some other sandboxing software.