Proxying Wayland for security

[Alyssa Ross]

Carsten Haitzler <raster at rasterman.com> writes:

>> > What I think would be of value is a standardized method to decide which
>> > wayland clients should be locked down and which should not be. This is
>> > currently "undecided". Something a compositor can easily look up given the
>> > client socket and then decide which protocol requests it will handle in
>> > which way.
>> 
>> Do I understand correctly that you're saying you'd like there to be some
>> sort of oracle, outside of the compositor, that the compositor could ask
>> what restrictions should be applied to a client?
>
> Yes. or more specifically I'd like it to be as simple and basic as possible.
> E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this is a .ini
> file format much like .desktop files so we can re-use parsers that most things
> have to eventually implement (how do you display sensible application info e.g.
> while alt-tab switching and icons for apps without doing some kind of .desktop
> file handling at some point? You can choose to never do this but then you may
> then not bother with more security either).
>
> Imagine there are 1 or more files that perhaps describe black or white lists in
> a fairly simple way that allow the compositor to limit functions.
>
> Personally, if I was going to lock security down 9have not gotten there yet -
> have other things to do before then). I'd be happy to support something like
> the above, but before that I'd do some of the following:
>
> 1 query UID/GID of the remote client. If it's not UID 0 and not UID of user
> running the compositor, auto-lock-down anything like copy & paste (eg behind
> such "are you sure" dialogs). We already do not support the screenshot protocol
> as it can be abused .. and the compositor has it's own ability to do
> screenshots and save them out to disk anyway. If we did support it, then it'd
> also do a "are you sure" thing too if UID/GID are not approved. I'd consider
> adding extensions to query SMACK label too if that was more widely used (or
> accept patches).
>
> 2. I'd also then after this add a custom "for my compositor only" white and
> black list of executable paths (probably a simple text file with a list of file
> globs per line like:
>
> deny  /usr/bin/firefox
> deny  /usr/bin/zoom
> allow /bin/screenshoot-tool
> allow /usr/bin/*
> allow /usr/local/bin/*
> deny  /*
>
> So simple walk the list from top to bottom finding first rule that matches.
> this is simple allow/deny but could make these custom rules like:
>
> rule allow=cnp,screenshot
> rule deny=
> rule allow-cnp=cnp
>
> Then use allow-cnp to allow clients to just do cnp. Of course this would just
> be me - but it's simple to maintain and reason about and flexible enough to do
> what is needed. Would have this file per user for sure (e.g.
> ~/.config/mycompositor/security/rules.cfg). The user local file parsed first for
> allow/deny rules then parse the system file for a master list for the whole
> system). Yes - it is coarse and only allows approval based on fill file paths.
> Yes - a binary could be written to /tmp/ or $HOME/ then deleted or renamed
> (vector of attack) which is why I'd have the last rule be a deny /*
> (everything) unless explicitly allowed and only explicitly allow known good
> directories of tools which have other system controls to limit abuse (writing
> of trojans there -= eg /usr/bin will be limited to root to write to).
>
> I am sure you spend far more time on all of this than I do and are more aware
> of the problem space, so I think you are much better positioned to create
> standards that are both simple to implement and powerful and secure. If all
> compositors agreed on the same ruleset to load and even used the same simple
> small security library to do this (e.g. you make a small lib that can be given
> a socket fd and then return a list of allowed actions - eg cnp,screenshot, ...)
> this would go a long way to perhaps having a standard everyone agrees on and
> is minimal effort to implement.

This sort of thing sounds good to me, especially paired with Simon's
secure context proposal[1].  I think it would be important to have it be
a little more complex than an allow/deny file, because it would be good
to give the user the ability to grant one-off permissions.  But from the
compositor's perspective, it wouldn't really matter how the library came
to its determination.  And users could switch between compatible
compositors while using the same authorization system.

The library could, for example, put up a graphical dialog asking the
user what to do.  Actually, is this starting to sound a lot like polkit?
I don't know a lot about polkit, but maybe I should start looking into
whether there could be an integration there.

> As per your example - if some compositors choose not to do this, then they
> would be less "secure" and users should be aware of this. That's up to them and
> the compositor developers to deal with.
>
> You get where I'm coming from. :)

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210728/66aecb3c/attachment.sig>