On 27/02/2014 18:01, Jasper St. Pierre wrote:
On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick
<[email protected] <mailto:[email protected]>> wrote:
Hey Jasper,
maybe I didn't understand what you're saying but why can't you use
the application authorization mechanism you're talking about in a
"WSM"? Wouldn't it make sense to make it independent of the
compositor?
Of course. That's why I'd love to have not just a "WSM" but a full
application authorization system that can be used not only for Wayland
requests but correspond to full capability management.
DBus is a perfect example. We should allow an app to only see the DBus
peers that it needs to see. So, org.gnome.Photos should never be able
to see or call APIs on org.kde.Konqueror or vice versa. But an app
might want a capability to interface with org.freedesktop.Telepathy.
And the same app might want access to a privileged
wl_notification_shell API so it can display a chat window in a special
corner of the screen when you get a message. And they'd probably want
read/write access to "~/Personal Data/Chat Logs/" or wherever the user
configured their chat logs folder to be, without access to "~/Porn/".
We need to think about the full surface of how applications will
interact with the system, without thinking about it in terms of
Wayland-only or DBus-only specifics. That's why I'm opposed to the
idea of "WSMs", and instead say we should start thinking about a full
application sandboxing and capability mechanism.
For a system like GNOME, for which our compositor, mutter, is used,
I'd never allow a different WSM to be configured, because then it
won't integrate with the rest of the system. A dialog pops up to ask
the user to allow wl_notification_shell, but they still can't use
org.freedesktop.Telepathy.
I think the policy should be compositor-agnostic, especially since some
may run multiple compositors at the same time. We thus need to abstract
the different compositors and I think that's the role of libwsm.
Just like LSM (Linux Security Module), libwsm is just a collection of
hooks that get called with a well-defined semantic, most-likely mostly
based on the Wayland protocol rather than the internal implementation of
the compositor.
Libwsm would indeed ship with a default policy that doesn't depend on
anything else than POSIX but it could be replaced very easily to use any
security decision engine, may it be SELinux or whatever new and shiny
decision engine appears in the future. The way I intend to do that is by
having libwsm forward the hooks to the right security backend. A
security backend would be a dynamically loaded .so by libwsm. libwsm
will know which .so should be loaded by reading its configuration file.
I already implemented such a system in PPassKeeper[1].
Just to make it clear, if no such abstraction is made, then all
compositors will require changes when a new decision engine becomes
available. But the worst problem is that each compositor will have
different hook points with different semantics and this will require to
write a different policy for each and every compositor. If I may say, I
think it sucks hard ;)
Your pluggable WSM just made the user unhappy.
You're killing the messenger, not the problem ;). In this case, the
problem would be the policy. WSM isn't PAM, I think having WSM only load
ONE security backend is just easier and simpler.
Cheers,
Martin
[1] http://www.mupuf.org/project/ppasskeeper.html
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
