Re: Proxying Wayland for security

[Simon McVittie]

On Wed, 28 Jul 2021 at 18:22:55 +0100, Carsten Haitzler wrote:
> 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.

Before that can happen, you need a concept of identity: you can't say
anything about what a client can or cannot do unless you can say which
client it is. D-Bus, X11 and other AF_UNIX protocols have the same problem.

You can get the euid from Linux SO_PEERCRED or SCM_CREDENTIALS, or other
OSs' equivalents. D-Bus, X11 and Wayland already do this. Each OS does this
differently but there's fairly wide coverage.

You can get the primary egid (but only the primary one!) from Linux
SO_PEERCRED or SCM_CREDENTIALS, or most other OSs' equivalents. D-Bus,
X11 and Wayland already do this.

You can get the supplementary groups from Linux SO_PEERGROUPS. At least
D-Bus already does this. I am not aware of non-Linux implementations,
but maybe some of the BSDs have a corresponding feature.

On Linux systems with some LSMs (SELinux, SMACK, or AppArmor with Ubuntu's
(non-upstreamed?) kernel patches) you can get the LSM security context
from SO_PEERSEC, but this only helps if your apps all have unique LSM
labels. D-Bus does this too.

Linux SO_PEERCGROUP and SO_PEERPIDFD have been proposed, but as far as I
know they are not in the upstream Linux kernel.

As noted elsewhere in this thread, process IDs can be retrieved reliably
from the same mechanisms as the euid, but reading extra information
from /proc/$pid/ is prone to race conditions and cannot (in general)
be done safely. SO_PEERPIDFD might defeat those attacks.

Flatpak deals with these attacks in D-Bus by using a separate, trusted
proxy process per Flatpak app, which is not under the control of the
Flatpak app, but has a marking (/proc/$pid/root/.flatpak-info) that can
be used to identify which Flatpak app it is acting on behalf of. Because
the proxy is not under the control of the Flatpak app, the Flatpak
app cannot force it to do what is needed to carry out the pid-reuse
attacks[0]. Similarly, Flatpak apps are sandboxed with seccomp, mount
namespaces and NO_NEW_PRIVS to make it difficult (hopefully impossible)
for them to alter their /.flatpak-info. This is all Linux-specific and
concerningly subtle, but probably good enough until the kernel provides
the building blocks to make something better implementable.

The approach typically used in e.g. GNOME is that Flatpak apps are treated
as semi-untrusted, but apps that are not in a container (in the main OS)
are treated as essentially part of the TCB[1], because in practice they have
the ability to subvert trusted processes (e.g. overwriting ~/.bashrc, or
dconf settings, or the login session's LD_PRELOAD or LD_LIBRARY_PATH,
and using that access to execute arbitrary code).

Ubuntu does a similar thing with AppArmor, treating typical end-user
applications (and in particular many Snap apps) as untrusted, but treating
things like an interactive terminal as part of the TCB.

smcv

[0] assuming the Flatpak app's permissions are not broad enough to allow
arbitrary code execution / sandbox escapes; if they are, then you have
already lost
[1] https://en.wikipedia.org/wiki/Trusted_computing_base;
for more useful terms, see also a design document I wrote for an
automotive OS that has the same multiple layers of security boundary
as a typical Linux desktop with e.g. Flatpak or Snap, namely:
* security boundary between the OS/system services and all users;
* security between one user and another
* security between two apps owned by the same user

https://www.apertis.org/concepts/security/#security-boundaries-and-threat-model
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[Simon McVittie]

On Tue, 21 Apr 2020 at 14:21:39 +0200, Benjamin Berg wrote:
> Yes, I agree that "user" is very similar. However, it cannot currently
> convey any information about whether a graphical session is already
> running or whether it is capable of spanning multiple logind sessions.

FWIW, the session bus integration in dbus refers to a "user-session"
(a user, in systemd-logind terms) consisting of one or more concurrent
"login sessions" (a session, in systemd-logind terms). I borrowed the
"login session" terminology from PAM, because I wanted a slightly longer
term than systemd's "session" - partly to be able to disambiguate exactly
what I was talking about, and partly because "session" already means
something a bit more abstract and undefined in D-Bus.

The use of "user" in systemd-logind is a little confusing, because you'd
naturally expect everyone in /etc/passwd to be considered a "user" - but
systemd-logind is a login manager, not a uid manager, so users who are
not currently logged in don't exist as far as systemd-logind is concerned.

If you can come up with better terminology for this, I'm happy to steal
it for dbus :-)

> Right
> now we assign "user" processes to one of the logind sessions by doing a
> best guess. That works great as long as the user has one graphical
> logind session. But, if this graphical session starts spanning multiple
> logind sessions, then the choice becomes more relevant as each of the
> sessions might for example have a different "Active" state.
> So, having something that represents the combination of all of them
> could bypass that problem in an elegant way. We would never need to
> "guess" the session, we would just always return the combined "user"
> session. This user session would for example be considered "Active" as
> [long] as any of the underlying logind sessions are active.

You can already do this, client-side, by aggregating information from
all of the login sessions that make up the user-session, if you want to.

There is no privilege separation between login sessions that share a uid
(and on practical systems they can all control each other by rewriting
each other's configuration files, using D-Bus to tell each other to
execute arbitrary code, or sometimes even ptracing each other), so there
seems little point in having any policies of the form "only processes
belonging to an active login-session can do xyz". Instead, I think the
way to think about it is "only processes owned by uids that have at least
one active login-session (and possibly some inactive ones) can do xyz".

For example, that means that if I have access to something as a result
of being the current active user (Wayland, X11 or or login/getty/bash
on the foreground virtual terminal), I should be able to get exactly
the same access by ssh'ing into that machine from another one, or by
having one of my cron jobs run - but then when I log out on the console,
or when I switch between VTs, my ssh sessions and cron jobs also lose
that privilege.

Sandboxed apps (Flatpak, Snap, etc.) should have less access than apps
that are in the desktop session's trusted computing base, but they normally
exist in the same login session as the trusted computing base *anyway*, so
the place to impose a privilege boundary is in the sandboxed app framework,
rather than between login sessions.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[Simon McVittie]

On Wed, 08 Apr 2020 at 11:02:36 +0200, Jonas Ådahl wrote:
> With that being said, it is possible to run multiple D-Bus sessions,
> where session busses are separate - it's just that noone actually does
> it as even if you have separate D-Bus sessions, separate
> $XDG_RUNTIME_DIRs, the sessions still share fundamental resources such
> as $HOME, and it is very likely that many applications you attempt to
> run will run into issues where they, running on separate "sessions" on
> the same user, will try to manage the same set of files in
> the users home directory.

We tried this: for about the first decade of D-Bus' existence, the
most common model was one session bus per X11 display (with dbus-launch,
sometimes packaged as dbus-x11). In practice, it didn't work very well
except in the trivial case where there is exactly one X11 session at a
time, and I now recommend doing something else.

The Mozilla family of browsers, which want to have a single instance
per home directory, are a common pain point.

Because we have been careful to keep backwards compatibility, recent
versions of the reference implementation of D-Bus expect an OS integrator
to decide what "session" means to them (or perhaps delegate that decision
to the sysadmin). If the semantics they choose result in two instances
of an application overwriting each other's files, D-Bus does not have an
answer to that, other than "perhaps you should have chosen differently".

These models are ready-made and already work:

- one D-Bus session bus per "user-session", using $XDG_RUNTIME_DIR/bus
  (my recommendation; dbus-user-session package in Debian)

- one D-Bus session bus per X11 display, by setting a separate
  $DBUS_SESSION_BUS_ADDRESS and some magic root window properties for
  each one
  (historical behaviour; dbus-x11 package in Debian; expect to see
  applications overwriting each other's changes)

and these are something you could put together from pieces by arranging
for $DBUS_SESSION_BUS_ADDRESS to be set appropriately, for example
by using dbus-run-session(1) or starting a dbus-daemon(1) yourself,
if they're what you want:

- one D-Bus session bus per Wayland display

- one D-Bus session bus per (PAM) login session

- one D-Bus session bus per just about anything else with a defined lifetime

See https://lists.freedesktop.org/archives/dbus/2015-January/016522.html
for what I mean by "user-session" - I'm using it as a jargon term here
because I'm not aware of any other name for this concept.

Non-reference implementations of D-Bus, like dbus-broker, might have
a more opinionated definition of what a session means, and decline
to operate in situations that they were not designed for. That's their
maintainers' design choice.

> even if you have [...] separate $XDG_RUNTIME_DIRs

Note that (unlike D-Bus) the freedesktop.org Base Directory specification
specifically defines XDG_RUNTIME_DIR to be one per what I call a
"user-session" above.  For example, if you are concurrently logged
in with uid 1000 using gdm on tty1, getty on tty2, a ssh session and
a remote desktop, according to the specification they must all share
a XDG_RUNTIME_DIR.

If you have more than one distinct XDG_RUNTIME_DIR for the same uid,
then you are not implementing the Base Directory specification, and
you might find that libraries and applications that were expecting
XDG_RUNTIME_DIR to be an interoperable Base Directory implementation
(including D-Bus implementations!) don't work as intended. In this case
you get to keep both pieces.

This is presumably why Wayland has $WAYLAND_DISPLAY, so that in the common
case you have a single Wayland compositor "wayland-0" per XDG_RUNTIME_DIR,
but in rarer cases (like debugging in a nested compositor), you can
have more than one compositor and tell your application to choose a
non-default one.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XDG_RUNTIME_DIR on a system with no "logins"

[Simon McVittie]

On Wed, 18 Dec 2019 at 13:10:14 +0100, Guillermo Rodriguez wrote:
> > > >But how is this done for a system where normally no users "log in",
> > > >e.g. a fixed-function embedded system with a graphical user interface?

Decide what "logging in" means for you, and make it work like that.

Imagine for a moment that your fixed-function embedded system was
running an ordinary desktop Linux system. You'd probably configure a
display manager (gdm or equivalent) to auto-log-in without displaying a
prompt or asking for a password, logging in as the user who owns the GUI
processes, to a special desktop session that runs the top-level process
of your embedded GUI (the same way a desktop session would run the
top-level process of a desktop environment, like gnome-session).

One, relatively heavy-weight, option is that you could literally do that.
For example, that's what SteamOS does for its games-console-style UI.
The advantage of that approach is that swapping from your embedded UI
to an ordinary interactive UI is just a matter of reconfiguring the
display manager.

The option you'll probably prefer is to aim to get the same practical
result, but in a simpler and more-hard-coded way: declare "launched
the GUI" to be the closest thing you have to "logging in", create an
XDG_RUNTIME_DIR that reflects that just before the first GUI process
starts, and clean it up after the last GUI process exits.  On an embedded
system, "after the last GUI process exits" is probably a power-off or
reboot anyway, so if you put the XDG_RUNTIME_DIR on a tmpfs it will get
cleaned up without you needing to do anything special.

If you're using systemd-logind, you can register a login session by
arranging for the pam_systemd PAM module to be entered (interactively or
otherwise), for example with PAMName in a system service unit; if you do,
systemd-logind will automatically allocate an XDG_RUNTIME_DIR for you,
for the duration of that service's lifetime. However, you mentioned SysV
init scripts, which suggests that you are probably not using systemd.

> OK so I can just "make up" a xdg dir which is not bound to any specific
> user. Although this obviously wouldn't meet the specs quoted above
> ("The lifetime of the directory MUST be bound to the user being logged
> in" ...)

You're the system integrator, so you get to choose precisely what "being
logged in" means.

> > If you invent XDG_RUNTIME_DIR like this, please also make sure to
> > adhere to the XDG specification requirements. Specifically, it is a
> > good idea to use a tmpfs for this. If it is backed by an actual
> > disk, it may incur unnecessary disk I/O, which in embedded systems
> > might be really bad.

To make it as easy as possible to adhere to the spec requirements and as
likely as possible that everything will work, I'd recommend mounting a
tmpfs on /run (which you are hopefully doing already), and then using
the same path for XDG_RUNTIME_DIR that systemd-logind uses, which is
"/run/user/$(id -u)" - that way, anything that incorrectly hard-codes
that path will still work. It's a bug to hard-code it, but there's no
particularly good reason to choose any other path either, so you might
as well make the same choice that systemd-logind did.

systemd mounts a separate tmpfs per user, but if your system doesn't
have any untrusted users or any need to prevent denial of service by
its users, then you can probably just use /run for everything.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Using libweston with GTK/GDK

[Simon McVittie]

On Mon, 03 Jun 2019 at 14:17:21 +0300, Pekka Paalanen wrote:
> For
> a test suite, you could use an environment variable to override the
> default search path, but for a manual launch that is a bit more
> inconvenient.

This is the solution that is generally recommended
in the GLib/GTK/GNOME stack whenever installed-tests
 are based on
the same programs that are used as build-time tests.

When run as a build-time test, the test assumes the environment variables
G_TEST_SRCDIR and G_TEST_BUILDDIR are set to the absolute path to the
source and build directories (the $srcdir and $builddir in Automake, or
the equivalents in CMake/Meson/etc.). You can use g_test_build_filename()
to construct paths to subdirectories of the source or build directory.
The build system (Automake, CMake, Meson etc.) is responsible for setting
those environment variables (and usually others like LD_LIBRARY_PATH,
XDG_DATA_DIRS and GI_TYPELIB_PATH) before invoking the build-time tests.

When run as an installed test, a test harness can set those variables
if desired. Otherwise, g_test_build_filename() looks at dirname(argv[0]),
removes a trailing "/.libs" if present, and assumes that this is correct
for both G_TEST_SRCDIR and G_TEST_BUILDDIR.

A test can also look for a program- or library-specific environment
variable (e.g. FLATPAK_BWRAP in Flatpak's tests), use it if set, and
otherwise assume that normal/production behaviour is desired (for example,
when FLATPAK_BWRAP is not set, Flatpak would typically use /usr/bin/bwrap
or /usr/libexec/flatpak-bwrap, depending how it was configured).

Look at (for example) GLib, Flatpak, libostree and dbus for some good
examples of this approach.

If you want to be able to invoke build-time tests by hand without going
through the build system ("make check" or similar), you could make the
build system generate a "run-test" script that looks something like this:

#!/bin/sh
set -e
export LD_LIBRARY_PATH="/path/to/build/.libs"
export GI_TYPELIB_PATH="/path/to/build"
export PATH="/path/to/build:$PATH"
export G_TEST_SRCDIR="/path/to/source"
export G_TEST_BUILDDIR="/path/to/build"
exec -- "$@"

by substituting variables in a source file that probably looks something
like this:

#!/bin/sh
set -e
export LD_LIBRARY_PATH="@builddir@/.libs"
export GI_TYPELIB_PATH="@builddir@"
export PATH="@builddir@:$PATH"
export G_TEST_SRCDIR="@srcdir@"
export G_TEST_BUILDDIR="@builddir@"
exec -- "$@"

and then run something like "./run-test ./my-unit-test --tap".

> Maybe
> always search in the build dir and hope that it is not found when
> properly installed.

Please don't do this: it is a potential security vulnerability. If a
user compiles your program or library in (for example) /tmp/my-build,
and at a later time or on another system an attacker is able to create
/tmp/my-build, then the attacker is likely to be able to gain control
over your program and execute arbitrary code with the privileges of the
user who is running it.

> FWIW, Weston uses environment variables for the test suite, and
> otherwise requires you to have installed first.

This sounds like essentially the same approach that the GNOME stack
recommends.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xwayland display variable

[Simon McVittie]

On Wed, 01 May 2019 at 14:30:52 +0300, Damian Ivanov wrote:
> export WAYLAND_DISPLAY=wayland-1
> GDK_BACKEND=x11 gedit //starts on wayland-0

If you are using GDK_BACKEND=x11, then gedit is not acting as a native
Wayland app, so it will not look at WAYLAND_DISPLAY. Instead, it will be
acting as an X11 app, which obeys the traditional X11 DISPLAY environment
variable (and in your case it happens to connect to an Xwayland instance
that is already associated with one of the Wayland displays, but the X11
backend in GTK has no knowledge of Wayland, so it can't know that).

If you want an application to appear on one of your Wayland displays,
irrespective of whether that application is using native Wayland or
X11 via Xwayland, then you need to put a matching pair of WAYLAND_DISPLAY
and DISPLAY in its environment.

Alternatively, if you let gedit use native Wayland (stop using
GDK_BACKEND=x11) it will respect WAYLAND_DISPLAY.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

[Simon McVittie]

On Mon, 21 Jan 2019 at 14:40:23 +0200, Pekka Paalanen wrote:
> On Mon, 21 Jan 2019 11:35:12 +
> Simon McVittie  wrote:
> > On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> > > Currently I have no clear opinion on what might be best. PID, UID and
> > > GID are quite poor for authorization anyway, I wish we could identify
> > > some more... fine-grained? At the application level? But is there even
> > > a useful definition of "an application" from the kernel point of view?  
> > 
> > Not really. To implement that, you'd need a race-free way to determine what
> > "application" your peer is part of. [...]
>
> That is enlightening. It makes me wonder what people are using
> PID/UID/GID for.

The uid makes a lot of sense *if* you are a security boundary between uids
(like the D-Bus system bus). Is the concept of a Wayland system compositor
still a thing? If it is, then uids are the first/highest level of being able to
distinguish between clients. The next level down is probably the trusted
computing base (TCB: all the trusted OS components, as a monolithic unit) vs.
sandboxed "apps" (Flatpak or Snap or similar), and below that you can start
distinguishing between different "apps".

If your Wayland compositor only serves one user (like GNOME Shell), then
a good use for the uid is "immediately disconnect anyone whose euid is
not me", like the D-Bus session bus does. If you do that, then
tautologously every surviving connection has the same euid, and the only
interesting boundaries are between TCB and "apps", and below that, between
one "app" and another.

Current Linux systems don't really put a useful security boundary between
OS-provided apps in /usr - they can all ptrace each other, they can all induce
each other to execute arbitrary code by overwriting ~/.config or ~/.bashrc or
some other well-known trusted file or by communicating over D-Bus, and so on -
so they're effectively all part of the trusted computing base. Technical users
rely on the fact that these apps all trust each other, too: xterm is an "app",
and so is emacs, but you'd be upset if you found that emacs wasn't allowed to
edit the ~/.bashrc that controls the shell in your xterm, or that your xterm
session isn't allowed to edit the files that are read by emacs.

That's why container-based app systems like Flatpak and LSM-based app systems
like Snap exist: their extra security boundaries give us a way to draw a line
between the TCB (including the compositor, the desktop session's configuration
UI like gnome-control-center, other desktop session bits like dbus-daemon and
gnome-settings-daemon, the terminal and other development tools, etc.), and the
rest of the app world.

I'm writing from the perspective of Linux and GNOME because that's what I use,
but the same is broadly true in all the non-Linux and non-GNOME "freedesktop"
environments, with some relabelling (for instance KDE clearly doesn't have
gnome-control-center, but it presumably has some other UI for global desktop
settings, which has essentially the same requirements as gnome-control-center
in terms of what it needs to be allowed to do).

Non-Linux systems obviously don't have the Linux-specific namespace-based
containers and LSMs, but if BSD users want sandboxed apps that are not in the
TCB, they presumably also have to use either something analogous to a Linux
container (jails?), or some DAC mechanism analogous to an LSM (Capsicum?), to
arrange for the sandboxed app to be prevented from affecting the TCB in ways
that it shouldn't.

Android uses an interesting hack to distinguish between "apps" securely: it
allocates a block of uids for each user account instead of a single uid,
allocates one uid per user account per "app", and runs each "app" under its
appropriate uid. This is not straightforward to retrofit onto an existing
ecosystem like the Unix/X11/Wayland/freedesktop stack, though: it only works
because Android is its own independent ecosystem from a UI and app development
point of view.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

[Simon McVittie]

On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> I don't think we can fix wl_client_get_credentials(), the semantics are
> very explicitly tied to the SO_PEERCRED behaviour. What I think we
> should do instead is to look into making a new API using
> SCM_CREDENTIALS.

D-Bus uses (and needs) similar functionality, so if you learn from
what D-Bus did, you can fast-forward past a lot of tedious portability
discussions that we already had.

There are basically two kernel API families that do this sort of thing:

* A socket option or function for the server to query the client's
  credentials without the client's help. This is GLib
  g_socket_get_credentials(). Known implementations in libdbus
  (GLib supports most of these, but I think not all of them):

  - Linux SO_PEERCRED
  - OpenBSD SO_PEERCRED (like Linux but with a different struct name)
  - NetBSD LOCAL_PEEREID (like Linux and OpenBSD but with different naming)
  - Solaris getpeerucred()
  - getpeereid() (available on multiple OSs but doesn't tell you the pid)

* A socket option or function for the client to send credentials attached
  to a message, which the server can trust to have been validated by the
  kernel. This is GLib's higher-level g_unix_connection_send_credentials() and
  g_unix_connection_receive_credentials(), or lower-level
  GUnixCredentialsMessage. There's only one implementation in libdbus,
  which I think is also in GLib:

  - FreeBSD/DragonflyBSD SOL_SOCKET/SCM_CREDS

See libdbus dbus/dbus-sysdeps-unix.c or GLib gio/gsocket.c,
gio/gunixconnection.c, gio/gunixcredentialsmessage.c for reasonably portable
versions of both of those, and in particular a good amount of the research for
which OSs support which APIs.

I think it's reasonable for SO_PEERCRED, LOCAL_PEEREID etc. to be combined into
one portable abstraction (as long as it has a way to say "unknown" for each
field, to account for protocols that give a superset or subset of what Linux
does) but I agree that SCM_CREDENTIALS makes more sense as a separate
abstraction. With hindsight, GLib gets this right where libdbus didn't.

Linux also has SO_PEERGROUPS which returns the supplementary groups (as
far as I know it is not documented whether the primary group is included,
so you have to get the primary group from SO_PEERCRED and combine the two).
libdbus is careful to distinguish between "we know the primary group is 42
and there might be other groups" (on older Linux or non-Linux, when
SO_PEERGROUPS didn't work) and "we know the process has exactly one group,
and it is 42" (on recent Linux, when SO_PEERGROUPS did work). In
application-level API we only expose group information in the SO_PEERGROUPS
case, where we can guarantee that we have the full list.

> But could we make it return obviously invalid values?

libdbus uses (pid_t) -1, (uid_t) -1 and (gid_t) -1 as the obviously-invalid
values. On POSIX systems, the -1 values for uid_t and gid_t are not suitable
for normal use due to their special meaning in setreuid() and setregid(), and
negative PIDs are not suitable for normal use due to their special meaning in
kill(), so that seems safe.

> As for new API, we could have wl_client_get_scm_credentials() or
> something, and automate the sending and receiving of SCM_CREDENTIALS at
> the first message to go through the Wayland connection. Does
> SCM_CREDENTIALS require at least one byte of actual data like
> SCM_RIGHTS does?

Yes it does, on at least some OSs. That's why the D-Bus wire protocol starts
with a single '\0', before the (ASCII) SASL handshake: on OSs that use
SCM_CREDENTIALS, the \0 has the credentials attached to it.

> Currently I have no clear opinion on what might be best. PID, UID and
> GID are quite poor for authorization anyway, I wish we could identify
> some more... fine-grained? At the application level? But is there even
> a useful definition of "an application" from the kernel point of view?

Not really. To implement that, you'd need a race-free way to determine what
"application" your peer is part of. The security boundary between unconfined
processes with the same uid is sufficiently nonexistent that this is unlikely
to be viable without using LSMs (like Snap's use of AppArmor) and/or containers
(like Flatpak's use of various namespaces).

Note that deriving information from the pid is easy to defeat if you have
access to a mechanism like setuid or filesystem capabilities, which
escalates capabilities while preserving the pid.
See .
It can also be defeated by pid reuse, although that's a harder attack.

In Linux, SO_PEERCGROUP has been proposed but not accepted; if that
existed then you'd be able to tell which cgroup the peer was in, for
example on systemd systems.

On systems with LSMs (SELinux, AppArmor, etc.) you can use SO_PEERSEC
to get the peer's LSM label, which is useful if your app framework uses
LSMs (for example Snap does, but only on systems booted with AppArmor
enabled).

Re: Session suspension and restoration protocol

[Simon McVittie]

On Wed, 20 Jun 2018 at 21:26:26 +0200, Roman Gilg wrote:
> On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie  wrote:
> > When we discussed this on #gnome-hackers we were talking about doing
> > restoration by passing the restored session ID as platform_data to the
> > Activate method defined by
> > https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
> > which would mean that for trivial/stateless apps, it would be enough to
> > ignore it and just start up, which DBusActivatable implementations like
> > GtkApplication will already do. Is there a reason why you've opted to define
> > a new method instead?
> 
> I think it makes sense to have a separate method, because a client can
> dbus-activate with the protocol any dbus-activatable app. Imagine a
> rogue client tries to dbus-activate an app, which is not written to
> use this extension but provides the Activate method.

A rogue client, you say. What's the threat model here?

If the threat model is that clients can be malicious, it seems like the
worst-case is that a malicious client can tell the compositor to trigger
activation of an app that, when launched, does something undesirable
or dangerous without further user interaction. Are you relying on an
assumption that apps that do something undesirable or dangerous on
activation will never implement the state-restore protocol?

If the threat model is that clients can be malicious, then it seems
a bad idea to have an Exec= fallback code path, because running an
executable (with unexpected command-line arguments that it might
misinterpret or ignore) seems like just as plausible a way to do bad
things as calling Activate() on it.

I think the real problem here is that the compositor or session manager
doesn't necessarily have a secure way to associate Wayland clients with
their D-Bus identities. Perhaps this means the protocol used to register
for this service should be based on D-Bus, not Wayland? Systems for
running untrusted or partially-trusted apps already need to "firewall"
access to the D-Bus session bus (for example Flatpak knows how to
do this), and in particular they need to make sure that untrusted apps
can't own well-known names other than their own.

If the register_session_suspension request was replaced by a
RegisterSessionSuspension() D-Bus method, then the implementation of
that method in the compositor or session manager could check that the
method call sender (unique name) matches the current owner of the D-Bus
well-known name corresponding to the requested desktop ID. For example,
if it gets a method call from unique name ":1.123" asking it to restore
desktop_id = "org.gnome.Builder.desktop" later, then it could ask the
dbus-daemon who currently owns "org.gnome.Builder", and only continue to
process the method call if the answer is ":1.123".

I can't think of an equivalent for that setup that would be suitable for
an Exec= fallback path.

> In this sense the protocol should be extended with the information
> that the Restore method should also return an error, if the
> restoration id is not found.

In case you're not aware, D-Bus method calls can always raise an
error, which behaves a bit like a C++/Java/Python exception, and
happens instead of returning their documented "out" parameters (if
any). Erorrs have a mandatory machine-readable *name* and an optional
(but strongly recommended) human-readable *message*. If a particular
error situation is an important part of your protocol design, you
can document a specific error name to be used in that situation, for
example "org.freedesktop.SessionSuspension1.Error.RestoreNotImplemented".
Callers must be robust against error names that they do not understand,
which they should treat as meaning "there was some other error".

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Session suspension and restoration protocol

[Simon McVittie]

On Tue, 19 Jun 2018 at 16:21:14 +0200, Michel Dänzer wrote:
> On 2018-06-19 02:22 PM, Simon McVittie wrote:
> > This indirect launching also avoids doing a fork-and-exec in the
> > compositor or session manager, which can be problematic under low-memory
> > conditions: the kernel needs to allocate enough virtual memory space for
> > a second copy of the parent process (even though the physical memory that
> > backs it is going to be copy-on-write, and in fork-and-exec it only exists
> > briefly and is mostly unmodified)
> 
> FWIW, /dev/dri/* files are supposed to be always opened with O_CLOEXEC,
> to prevent the file descriptors from leaking to children.

Sure, but that's close-on-exec, not close-on-fork. The kernel doesn't
know you aren't going to continue executing application-level code in
both parent and child[1].

> There were
> bugs in libdrm meaning this didn't always happen, but those are fixed in
> current upstream.

Just about everything is *meant to be* opened O_CLOEXEC, but that doesn't
mean it is :-)

smcv

[1] Never do this if your process might be multi-threaded, and probably
don't do this even if it's known to be single-threaded
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Session suspension and restoration protocol

[Simon McVittie]

On Tue, 19 Jun 2018 at 13:56:22 +0200, Markus Ongyerth wrote:
> P.S. I just thought about this ab it more, and something else came to my mind:
> How is env passed with dbus activation? afaik the session bus does not run in 
> under the compositor, so if we aren't on wayland-0 (which can happen very 
> well 
> in dev situations, and multi seats, and ...) we'd have to tell the client as 
> well.

The session bus can run either inside or outside the compositor. It
depends how you have designed your OS, and what you consider "the session"
to mean. Desktop infrastructure can tell the dbus-daemon what environment
variables it should pass to its child processes (but there can only be
one answer at a time).

In the terminology of
https://lists.freedesktop.org/archives/dbus/2015-January/016522.html
a "session = login session" world would have one of these:

user session for uid 1000 (owns XDG_RUNTIME_DIR)
\- login session c1
\- compositor
\- compositor-launched app
\- session bus
\- D-Bus-activated app

or

user session for for uid 1000 (owns XDG_RUNTIME_DIR)
\- login session c1
\- session bus
\- D-Bus-activated app
\- compositor
\- compositor-launched app

(in the latter case you'd probably want to use
UpdateActivationEnvironment() to send the WAYLAND_DISPLAY to the session
bus)

while a "session = user session" world would have this:

user session for for uid 1000 (owns XDG_RUNTIME_DIR)
\- systemd --user (optional)
\- systemd-launched app (possibly done via D-Bus)
\- session bus
\- traditionally D-Bus-activated app
\- login session c1
\- compositor
\- compositor-launched app

(again, you could use UpdateActivationEnvironment() to send the
WAYLAND_DISPLAY to the session bus if necessary)

The Activate() method defined by the Desktop Entry Specification passes
a key:value map of arbitrary "platform data" to the activated process.
It would be reasonable to include something like
{'wayland_display':<'wayland-1'>}, meaning "use this Wayland display if
possible, overriding the environment". (However, if the app only supports
connecting to one Wayland display at a time, you're still stuck.)

> Thinking about clients that may have multiple instances, but not shared 
> sessions, e.g. some IDE with two projects opened.
> iiuc the activation would start one process, which could then either restore, 
> or open as normal, but when another project is openend, the process is 
> already 
> running and has to start another instance.
> Over just having a single point of entry where it's started with restoration, 
> or without.

Clients with multiple instances (an IDE with a process per project) are a
better fit for a fork-and-exec design, yes.

Conversely, clients with a single instance (an IDE with one big process
that can host multiple projects each in their own top-level window,
like emacs with emacsclient, or GNOME Builder) are a better fit for an
instance-as-a-service design. Clients with a single top-level process
that manages a hierarchy of internal "helper" subprocesses, like web
browsers, are probably also a better fit for the design.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Session suspension and restoration protocol

[Simon McVittie]

On Tue, 19 Jun 2018 at 11:18:17 +0200, Markus Ongyerth wrote:
> On 2018/6月/18 05:05, Roman Gilg wrote:
> > * using D-Bus interface only to secure against sandboxed clients
> What? Why exactly? When I first read this, I expected that the client is 
> supposed to use the portal stuff to call out of a sandbox, but reading 
> through 
> the actual protocol, I think the only usage of D-Bus is to launch the 
> applications from the compositor?

Any app implementing DBusActivatable (see the Desktop Entry Specification
for more details) needs to be able to receive method calls from desktop
infrastructure outside its sandbox anyway. For instance, Flatpak always
allows method calls into the sandbox, while restricting method calls
out of the sandbox according to app-specific rules.

> Since this needs explicit client support either way, IMO this could be 
> implmented by adding a required cmdline argument (e.g.
> --org-freedsktop-restore=UID) instead.

In desktop environments that support it, it's advantageous to launch apps
as D-Bus services, or even as systemd user services if they support
being launched like that (dbus-daemon will automatically delegate
activation to systemd --user where supported), so that they always run
in a reasonably consistent execution environment. If various different
components (compositor, main menu if it's separate from the compositor,
random app that wants to open a web page, etc.) launch an app using
fork-and-exec with the Exec= command line from its .desktop file, then
the app will inherit its execution environment (environment variables,
file descriptors, rlimits, other process flags) from an arbitrary parent
process, depending on the precise details of how they were launched. If
they're DBusActivatable, they'll all be children of systemd --user (if
supported) or dbus-daemon --session (if not), making their execution
environment a lot more predictable.

This indirect launching also avoids doing a fork-and-exec in the
compositor or session manager, which can be problematic under low-memory
conditions: the kernel needs to allocate enough virtual memory space for
a second copy of the parent process (even though the physical memory that
backs it is going to be copy-on-write, and in fork-and-exec it only exists
briefly and is mostly unmodified), and when a compositor has your GPU's
address space mmapped, that's actually a significant practical problem.
I think Endless have had trouble with this in GNOME Shell on 32-bit -
there's easily enough address space to have the GPU mmapped once, but
if GNOME Shell does a fork-and-exec, the child process briefly has the
GPU mmapped for a second time, and there isn't always enough address
space free to do that.

The DBusActivatable protocol doesn't support sending arbitrary
command-line arguments to the launched app, because in general,
command-line arguments are not meaningful for an app that is already
running. (It does support sending the URLs of files to be opened.)
Assuming we want to avoid always having to fall back to fork-and-exec,
which is undesirable for the reasons above, we'll need some way to
pass the state to restore via D-Bus - either a new method call as Roman
proposed here, or the platform_data argument to Activate() as I suggested.

It would be possible to have a D-Bus preferred path and a fork-and-exec
fallback path that are defined to be equivalent, like the Desktop
Entry Specification does now for ordinary launching and for "Desktop
Actions". That would have to work via either a command-line argument or an
environment variable, because in fork-and-exec world those are the only
tools we have. However, the meanings (and even syntax) of command-line
arguments are conceptually "owned" by the app author, not by some third
party like freedesktop.org; and environment variables are undesirable
here because they inherit to child processes.

Having two code paths also means that a high-quality implementation has
to test and support both (potentially forever), while in a lower-quality
implementation the less-preferred code path will probably regress at
some point, which is bad if your compositor or app is in the minority
that is relying on it.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Session suspension and restoration protocol

[Simon McVittie]

This document might be useful for the D-Bus side:
https://dbus.freedesktop.org/doc/dbus-api-design.html

On Mon, 18 Jun 2018 at 17:05:25 +0200, Roman Gilg wrote:
> In certain high levels the compositor will ask the client through a
> special D-Bus interface to restore its internal state. This interface
> must be made available by the client on the address specified by the
> desktop_id argument.

A D-Bus "address" isn't what you think it is. I think you mean a
*well-known bus name*, for example "org.gnome.Builder".

Note that GNOME Builder's desktop ID is "org.gnome.Builder.desktop"
but its D-Bus well-known name is "org.gnome.Builder", and any other
DBusActivatable application will follow the same pattern (it's part of
the Desktop Entry Specification). Be clear about which one you mean.

Strictly speaking, you should also specify that this is a name on the
*well-known session bus* (or "session bus" for short).

I would recommend having a canonical XML description (somewhere) for
the D-Bus side of this interface, similar to the one in the text of
https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus

> The special interface name for the D-Bus call is
> zxdg_session_suspension_v1

That isn't a valid D-Bus interface name. D-Bus interface names look
something like "com.example.SessionSuspension1". The equivalent of Wayland's
xdg_ is org.freedesktop. If you are proposing names in that namespace you
should mention them on the x...@lists.freedesktop.org list, although I think
it'd be OK to say "please send feedback to the Wayland list".

To call a D-Bus method, you also need an object path. There are two
reasonable object paths for a singleton object related to the Desktop
Entry Specification's DBusActivatable protocol: either reuse the object
path corresponding to the desktop ID (for example /org/gnome/Builder),
or use an object path corresponding to your interface name
(for example /org/freedesktop/SessionSuspension1). If you use the
object path corresponding to the desktop ID, then it will be very
awkward to implement this protocol without involving the implementation
of DBusActivatable (for instance GApplication/GtkApplication in GNOME),
but the GApplication/GtkApplication or equivalent is probably the right
place to implement this protocol anyway, so either could work.

(The reason why object paths and interfaces are separate is that in a
more complex design, there might be many implementations of the same
interface in a process, for instance media players that provide one
object per file/track/stream at different object paths, each of them
implementing org.gnome.UPnP.MediaItem2. If interfaces are like abstract
base classes, then object paths are like pointers.)

Do you intend the D-Bus side of the protocol to be equally useful to
X11 apps, or is this a Wayland-only thing?

> and the method being called by the
> compositor on this interface is simply called 'restore'

D-Bus method names are conventionally in camel-case, so 'Restore'.

When we discussed this on #gnome-hackers we were talking about doing
restoration by passing the restored session ID as platform_data to the
Activate method defined by
https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
which would mean that for trivial/stateless apps, it would be enough to
ignore it and just start up, which DBusActivatable implementations like
GtkApplication will already do. Is there a reason why you've opted to define
a new method instead?

> compositor will issue on the next Wayland server launch the D-Bus
> command:
> 
> org.foo.bar /zxdg_session_suspension_v1 restore(1234)

D-Bus has no concept of a "command". The jargon term you're looking
for is a *method call*, which is one of several types of *message*.
If you want a pseudocode notation, you might want something like this:

a D-Bus method call to a destination given by the desktop_id,
with object path /org/freedesktop/SessionSuspension1, interface
org.freedesktop.SessionSuspension1, method name Restore, and the
client_id as a uint32 parameter, similar to the result of this
dbus-send(1) command line:

dbus-send --type=method_call --destination=org.gnome.Builder \
/org/freedesktop/SessionSuspension1 \
org.freedesktop.SessionSuspension1.Restore \
uint32:1234

(Of course, compositors or session managers should normally implement
this in-process instead of by running dbus-send(1).)

>   summary="desktop file id to restore the client via d-bus"/>

Does this include .desktop or not? GNOME Builder's desktop ID is
"org.gnome.Builder.desktop" but its D-Bus well-known name is
"org.gnome.Builder", and any other DBusActivatable application will
follow the same pattern (it's part of the Desktop Entry Specification).

>   The quit state ends when the compositor sends the D-Bus signal to
>   

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Simon McVittie]

On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote:
> On 5 June 2018 at 23:06, Daniel Stone  wrote:
> > +  - apt-get -y --no-install-recommends install build-essential automake 
> > autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev 
> > libpixman-1-dev libpng-dev libjpeg-dev libcolord-dev mesa-common-dev 
> > libglu1-mesa-dev libegl1-mesa-dev libgles2-mesa-dev libwayland-dev 
> > libxcb1-dev libxcb-composite0-dev libxcb-xfixes0-dev libxcb-xkb-dev 
> > libx11-xcb-dev libx11-dev libudev-dev libgbm-dev libxkbcommon-dev 
> > libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libxcursor-dev 
> > libmtdev-dev libpam0g-dev libvpx-dev libsystemd-dev libinput-dev 
> > libwebp-dev libjpeg-dev libva-dev liblcms2-dev git
> 
> I think this can be simplify the explicit list to:
> apt-get -y --no-install-recommends build-dep wayland

Only if the latest version of wayland has the same build-dependencies
as the (likely much older) version visible in the Sources index
for the container's apt configuration. If the container is
Debian 9 'stretch' (released about a year ago) then apt-get build-dep
will get the build-dependencies of wayland 1.12.0, according to
.

> > +  - make -j4
> > +  - make check
> > +  - make install
> > +  - make distcheck
> I was under the impression that "make -j4 distcheck" is enough

install and check both imply (depend on) a normal build, so that one is
redundant.

distcheck runs the tests like check does, but differently-configured,
so for full coverage you might want to do both.

Similarly, distcheck runs "make install", but into a temporary directory,
not the requested $PREFIX.

> Alternatively it's worth setting MAKEFLAGS="-jX" once so it's used across all.

Using -j would definitely help for "make distcheck".

If parallel install works, it would be good to test it so that it stays
that way: quite a lot of projects can build correctly in parallel, but
don't work reliably for "make -jX install".

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Simon McVittie]

On Thu, 22 Mar 2018 at 08:22:23 -0400, Simon Ser wrote:
> I think we really do mean "decorations" and not "window management". 
> Decorations
> are used for window management, but their scope is larger - they are also user
> interface components.
> 
> For instance, I can think of GNOME [1] and elementary OS' [2] dialogs, which 
> do
> have decorations (rounded corners, shadows) but for which decorations cannot 
> be
> used for window management operations (they are purely aesthetic).

Those dialogs still have all the window-management operation widgets that
the application designer wants them to have - that just happens to mean
"none" in this case.

Contrast with the same dialogs in a SSD environment, where they get all
the window-management operation widgets that the *window manager*
designer wants them to have (which might be different).

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 1/2] wayland-egl-symbols-check: add ARM specific glib entrypoints

[Simon McVittie]

On Tue, 20 Mar 2018 at 11:10:44 +, Emil Velikov wrote:
> Subject: [PATCH wayland 1/2] wayland-egl-symbols-check: add ARM specific
> glib entrypoints

ARM-specific *glibc* entry points, GLib has nothing to do with this :-)

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 2/2] wayland-egl: Make symbol test fail on failure

[Simon McVittie]

On Mon, 19 Mar 2018 at 13:39:30 +, Daniel Stone wrote:
> On 19 March 2018 at 13:27, Emil Velikov  wrote:
> >> I'd not realised AC_PROG_NM didn't set a full path. Brilliant. Maybe
> >> replace test -x "$NM" with $NM -V >/dev/null 2>&1? Or just trusting it
> >> works if it's non-empty is fine too.
> >>
> > I'd go with non-empty - everything else seems like an overkill.

If you ever want the more full version for something else, I think

command -v "$command" >/dev/null

is the canonical way to ask a POSIX shell "could I invoke $command?".
It exits successfully if $command is a function, an alias, a shell
built-in, the basename of an executable in $PATH, an executable found
by relative or absolute path, an alias or a shell reserved word.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] weston: remove SEGV and ABRT handlers

[Simon McVittie]

On Wed, 07 Feb 2018 at 15:12:48 +0200, Pekka Paalanen wrote:
> Weston handles all other signals via signalfd(), these were the only ones
> that used the signal()/sigaction() kind of API.

That's good. The traditional pipe-to-self is basically an implementation
of signalfd() for kernels that don't necessarily have it, if I understand
it correctly.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/2] weston: remove SEGV and ABRT handlers

[Simon McVittie]

On Wed, 07 Feb 2018 at 12:51:14 +0200, Pekka Paalanen wrote:
> Catching an ABRT is kind of ok, catching a SEGV is russian roulette. We
> have been quite lucky with it, but I've started hitting crashes inside
> malloc() which causes a deadlock when our SEGV handler needs to malloc()
> as well (weston_log_timestamp()).

This isn't unique to SIGSEGV: inside any POSIX async-signal handler,
you can only (portably, safely) use functions that are documented to be
async-signal-safe, which basically means syscall wrappers. See
signal-safety(7) on a Linux system.

(If anything in the Wayland/Weston stack reloads configuration on SIGHUP,
it should probably use the standard "pipe-to-self trick", like e.g.
dbus-daemon does - write a byte to a pipe using async-signal-safe write(),
poll that pipe in the main loop, and reload configuration from the main
loop whenever one or more bytes can be read from the pipe. That's a
safe pattern.)

> Therefore, this code does more harm than it is useful, so remove it. We
> also drop an optional dependency to libunwind.

I am not a Wayland reviewer, but I think this is an excellent idea. The
best signal handlers are SIG_DFL and SIG_IGN :-)

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston stuff: fractional HiDPI, FreeBSD, Rust

[Simon McVittie]

On Thu, 18 Jan 2018 at 18:25:02 +, Daniel Stone wrote:
> I do have another suggestion though: can you please change the platform
> checks (#ifdef __linux__ and #ifdef FreeBSD) to instead be feature
> checks? For example, CLOCK_MONOTONIC_RAW is behind a Linux ifdef and
> CLOCK_MONOTONIC_FAST is behind a FreeBSD ifdef. There's no reason
> either platform couldn't start providing the other's clocks.

Based on my experience with dbus, feature checks are desirable in general,
but I'd recommend leaving a comment

#ifdef CLOCK_MONOTONIC_RAW
  /* Used on Linux >= x.y and possibly elsewhere */
  ... code ...
#endif

or even an #error-based pseudo-assertion like this:

#ifdef CLOCK_MONOTONIC_RAW
  /* Used on Linux >= x.y and possibly elsewhere */
  ... code ...
#elif defined(__linux__)
# error Not having CLOCK_MONOTONIC_RAW on Linux is a regression
#endif

to indicate which features are expected to be present on which platforms.
Before I did the necessary archaeology in 2013, dbus supported 5 different
ways to do AF_UNIX credentials-passing, one of which (*BSD-compatible
LOCAL_CREDS) turned out to have been redundant with other mechanisms on
all known platforms, and had regressed in 2009 such that it didn't actually
work. https://bugs.freedesktop.org/show_bug.cgi?id=60340

(Admittedly, credentials-passing and other murky corners of AF_UNIX are
perhaps the place where feature-checks are least useful, because they
have very little standardization, with each specific mechanism tending
to be unique to one or two platforms anyway.)

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] inputfd - direct input access protocol

[Simon McVittie]

On Wed, 05 Apr 2017 at 17:45:51 -0700, Roderick Colenbrander wrote:
> I wonder how Valve is doing this on Steam as with the Steam
> Controller, which I haven't used. I think they are allowing it to
> replace keyboard and mouse kind of. Curious how they are solving this.
> My guess is they are actually spoofing a mouse for game compatibility.

It pretends to be a mouse, a keyboard and an XBox 360 gamepad all at
the same time, possibly with the help of uinput (I'm somewhat hazy on
the details, having done my best to forget it all once I got it working).
The events that it produces are configurable per-game, so for instance the
right touchpad might be generating right analogue stick movements, mouse
motion, or even keypresses, but I don't know whether that's done by remapping
events in user-space or by asking the device firmware to send different
packets over USB.

Steam also has in-home streaming, which relays input events across
the network from the viewer/controller machine (a PC or Steam Link)
and AIUI uses uinput to emulate all the right devices on the machine
that is actually running the game.

[Disclaimer: I worked on some SteamOS code a while ago, but it was
packaging/package management and not input or graphics, so this is
entirely an ordinary user view from the outside. For non-speculation
you'd have to ask Valve.]

S
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Interface for injection of input events

[Simon McVittie]

On Tue, 28 Mar 2017 at 15:33:41 -0700, Jordan Sissel wrote:
> I am interested in the security concerns here, but are there reliable barriers
> between different processes run by the same user in the same desktop session?
> What is the threat model y'all are defending against?

D-Bus was mentioned earlier in this thread, and the security model that
we keep telling people applies there is:

* The uid who ran the session bus (dbus-daemon --session) can connect to it
* That uid is totally trusted
* If you don't like that, sandbox your untrusted app, don't let it
  open the normal D-Bus socket, and use some sort of filtering proxy
  like Flatpak does instead

 is a future design
for having dbus-daemon offer less-trusted sockets in parallel with the
totally trusted one, which would obsolete Flatpak's D-Bus proxy.

Several D-Bus services that listen on the session bus offer arbitrary
code execution, a user can typically ptrace their own processes and
achieve arbitrary code execution, and a user with write access to the
home directory can achieve arbitrary code execution by writing
configuration files - so there is no point in trying to provide a
privilege boundary unless you have either a container like Flatpak,
or an LSM like AppArmor, or both.

If Wayland is aiming to be at a higher level of security isolation than
the D-Bus session bus - something you can bind-mount into your container
and not worry about, without introducing secondary sockets like fd.o
#100344 - then of course its tradeoffs might not be the same as for D-Bus.

S
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Collaboration on standard Wayland protocol extensions

[Simon McVittie]

On 29/03/16 13:11, Drew DeVault wrote:
> I see what you're getting at now. We can get the pid of a wayland
> client, though, and from that we can look at /proc/cmdline, from which
> we can get the binary path.

This line of thinking is a trap: rummaging in /proc/$pid is not suitable
for use as a security mechanism. If a client can queue up a malicious
privileged action (stuff it into the socket's send-buffer), and then
race with the compositor to exec() something that would legitimately be
allowed to take that action before the request is processed, then you lose.

See <https://bugs.freedesktop.org/show_bug.cgi?id=83499> for details of
the equivalent in D-Bus. Mainline dbus on Unix was never vulnerable to
this (because we use credentials-passing to get the uid), but there used
to be an out-of-tree LSM integration patch set (for Maemo) that was.
(That bug was about documenting the attack so that we never accidentally
introduce it.)

If you want to map processes to executable-based privilege domains in a
way that cannot be faked, you will have to use their LSM labels
(SELinux, Smack or other xattr-based labelling, or AppArmor or other
path-based labelling) which are specifically designed to do this. A
Wayland equivalent of D-Bus' GetConnectionCredentials() would probably
be useful.

    S
-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel