Proxying Wayland for security

Wed Jul 28 17:22:55 UTC 2021

On Wed, 28 Jul 2021 10:56:40 +0000 Alyssa Ross <hi at alyssa.is> said:

> 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.

Forget then looking up exe from PID unless we have some kernel mechanism to
lock this down (ie reliably report a fd or path to the exe that created the
socket). this does indeed have issues as per gitlab thread with interpreted
langauges... as this would always report the interpreter...

> 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.

no... no.. the library should not put up the dialog. it should tell the
compositor what is and is not allowed - let the compositor do whatever it needs
to do to figure this out.

but in the end almost everyone wants some way to differentiate what clients can
and cannot do based on some kind of sandboxing and rules. they don't want to
write all of that code. they do want to know if that client should be allowed
"full reign" or be limited (only allowed some things) and then do the specific
filtering based on compositor design. some compositors may talk to some utility
they run. some will be able to pop up their own dialogs as they have a full
toolkit to do it with etc.

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

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com