Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
GrootBlouNaai opened this issue Jun 28, 2024 · 3 comments

Comments

@GrootBlouNaai
Copy link

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
Copy link
Owner

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
Copy link

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

@probonopd
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants