mupuf / libwsm

Wayland Security Module library for wayland compositors

Lib Wayland Security Modules

LibWSM is a framework that supports security decision making on Wayland-based graphic stacks. It implements methods for expressing security decisions on privileged interfaces and an interface for security engineers to write backends. It is shipped with a default backend that allows per-user and per-application security policies. Those policies can be extended without limits to support per-compositor decisions, compositor-specific capabilities and even custom security decisions.

This project was designed and developed by Martin Peres and Steve Dodier-Lazaro. It is maintained by Martin Peres. The code is hosted on GitHub.

Sources of policy

When a policy is not set for a client;capability;object set, libWSM will soft-deny actions. If policies are available, the default backend will take them into account in the following order from top to bottom:

• The policy that matches the client's executable and uid
• The system-wide policy that matches the client's executable
• The generic policy that matches the client's uid
• The system-wide generic policy for all clients
• Soft Deny if no policy is available

Backends can give four recommendations by default:

• Allow: the policy allows the action to be performed. It is recommended to allow the action.
• Soft allow: there probably is nothing wrong, but attacks could be carried out. It is recommended to provide feedback to the user about the action being performed.
• Soft deny: the requesting app has not obtained the permission to perform the action. It is recommended to seek an alternative way to provide permission if desired (e.g., trusted UIs or permission prompt)
• Deny: the action has been explicitly written as denied in the policy. It is recommended to follow the policy and deny the action without alternative.

Other permissions can be defined. As a rule of thumb, when a compositor does not recognise a permission, ‘Deny’ should be followed.

Capabilities related to the Graphic Stack

The following capabilities are made available. default: indicates what the default policy shipped with the default backend states.

WSM_SCREENSHOT default: soft-deny Ability to take a still screenshot of the whole screen

WSM_SCREENSHARING default: soft-deny Ability to record the screen continuously

WSM_VIRTUAL_KEYBOARD allow/inject-only/filter-only/soft-allow/soft-deny/deny default: soft-deny Ability to inject or filter input on the keyboard

WSM_VIRTUAL_POINTING default: soft-deny Ability to modify the position of the pointer and simulate clicks

WSM_GLOBAL_KEYBOARD_SEQUENCE object: key sequence default: soft-deny Ability to receive global keyboard sequences when not on focus

WSM_FORWARD_RESERVED_KEYBOARD_SEQUENCE object: key sequence default: soft-deny Ability to receive reserved keyboard sequences instead of compositor when on focus

WSM_FULLSCREEN default: soft-allow Ability to use the entire screen

WSM_CLIPBOARD_COPY default: allow Ability to copy to the clipboard

WSM_CLIPBOARD_PASTE default: soft-deny Ability to paste from the clipboard

WSM_RAISE_FOCUS default: soft-allow Ability to raise the window and grab focus programmatically

WSM_NOTIFICATION_API default: soft-allow Ability to use the libnotify API to raise notifications

WSM_CUSTOM_NOTIFICATION_API default: soft-deny Ability to build custom notification UIs and have them displayed (i.e., raised and positioned for a set duration) by the compositor

Possible future capabilities not related to the Graphic Stack

DSM_RECORD_VIDEO default: soft-deny Ability to read data on video capture devices

DSM_RECORD_AUDIO default: soft-deny Ability to read data on audio capture devices

DSM_USE_PASSWORD_STORE default: soft-allow Ability to use password store APIs

DSM_PRIVILEGED_HEADLESS default: soft-allow Ability to perform privileged actions without having a GUI

DSM_SESSION_LOCKER default: deny Ability to lock the user session

DSM_AUTHENTICATION_UI default: deny Ability to act as an authentication UI

DSM_PERMISSION_UI default: deny Ability to act as a permission UI

Things LibWSM is currently bad at

Expressing policies that apply only in certain modes of a Wayland compositor This won't be fixed unless a compositor developer can convince us that their compositor implements different desktops that their users conceive as entirely distinct (e.g., KDE?)

Adding options to capabilities e.g., on the notification API, different decisions for focus raising, custom UI, actions, UI positioning... Support is desirable but will complicate policy a great deal. Feedback is wanted from DE developers

libwsm's Issues

Verify compatibility with KDE

Contact KDE developers to identify:

• custom and implemented capabilities
• current sources of policy and criteria for security decision making

Provide a central policy override for emergency incident response

Provide a method to enforce a deny on a specific capability for all applications regardless of their policies. This goes against the philosophy of WSM Default and should be used sparingly as a way to hot patch systems when an incident occurs. It should be advertised this way and understood this way by WSM Default.

Reserved keyword: Exec=!
Considerations:

• WSM Default must log all decisions made on an emergency policy override and complain loudly
• This must be advertised as only for emergency response!
• Requires hooking the override policy in get_permission to allow dual sources of policy
• Also means this backend could be plugged on top of another one
• Only [Soft] Deny is applicable. When a rule isn't present in the override source of policy, the normal policy file of an app:UID couple should be used

Methods: TBC

Improve performance at decision-making time

Currently when loading the config file I keep everything stored as strings. For non-custom decisions, better perf could be obtained by duplicating permissions as shorts in the weston config object. This would allow returning a decision with less strcmp and no strdup/free.

Implement full templates

Templates are a WSM Default way to indicate that an app's policy is written elsewhere, as a whole.

Reserved syntax: Exec=? and Template= and TemplateName=

Mandatory design/code changes:

• new keywords in language...
• complexifies the policy finding code for client_new() as links must be resolved up to four times (for each policy candidate)
• define behaviour when template links are not found, or log issues properly at least

Cannot override /usr/var location for policies

/usr/bin/cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib -DCMAKE_BUILD_TYPE=None '-DCMAKE_C_FLAGS=-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG' '-DCMAKE_CXX_FLAGS=-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG' '-DCMAKE_Fortran_FLAGS=-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG' '-DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' '-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' '-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF -DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules -DWSM_DEFAULT_POLICY_PREFIX=/usr/share/wsm-policy

Despite requesting /usr/share/wsm-policy with an override, the cmakefiles still install the policy files into /usr/var/share/.

Verify compatibility with XFCE

Contact XFCE developers to identify:

• custom and implemented capabilities
• current sources of policy and criteria for security decision making

The provided way to identify applications is unreliable

Unless I am worse at C than I thought, the implemented way to determine the application binary path is to read the /proc/[pid]/exe symlink.

This is sadly not a reliable way. The symlink is always given in the applications mount namespace, not the compositors mount namespace.
With unprivileged user namespaces (which afaik most distributions have available for lxc/docker/etc.) any user application can abuse this to gain any path.

I think this can be (paritally) mitigated by checking /proc/[pid]/ns/nmt and compare it with /proc/self/ns/mnt.

As secondary problem, applications that use interpreters (such as python) will show up as the interpreter. And sadly /proc/[pid]/cmdline is not reliable either to determine which file is interpreted.

Verify compatibility with Weston

Contact Weston developers to identify:

• custom and implemented capabilities
• current sources of policy and criteria for security decision making

Verify compatibility with Tizen

Contact Tizen developers to identify:

• custom and implemented capabilities
• current sources of policy and criteria for security decision making

Add build prerequests to INSTALL

libwayland-dev installation is needed for Ubuntu 17.10. But I am not sure the same package name used on other distros.

Implement nested sections

Some compositors implement modes or multiple environments and would like different policies for such environments.

Mandatory design/code changes:

• add way to change compositor name or much better to provide/retrieve it at permission granting time
• explore methods to prevent race conditions on compositor identity when granting permissions
• explore methods to prevent delegating statefulness management to compositors to avoid errors; find a clear method to guarantee the validity of an access decision when it is received by the compositor

Two appraches at least:

1. get compositors to advertise new names and use a section per mode

• No added complexity to policy reading
• But added length: harder to author meaningful policies (must copy/paste additions in each section) and even more so to edit them programmatically (are sections identical by coincidence or because they should be sync'd?).
• Trivial code changes

Changes to codebase:
ø

2. implement subsections

• More compact, faster to edit for experts
• Less readability within file
• Might require editing the parser substantially
• Added complexity throughout whole backend, might need to change get_permission to expose contextual cues on compositor identity

Changes to codebase:

• add a subsection syntax for the files
• make parser understand subsections
• rework weston_config_get_section* functions

Make sure all the clients have been freed before allowing wsm_fini()

wsm_fini() should either kill all the clients or return an error if some clients still depend on it.

We could implement that by having the list of clients in libwsm or just count the number of clients. I would prefer having the first as the more information we have, the better!

Version checks in default backend

The default backend does not yet support version checks.

Code changes:

• add version checking code when files are parsed, and reject incorrectly versioned files for now.

Verify compatibility with GNOME

Contact GNOME developers to identify:

• custom and implemented capabilities
• current sources of policy and criteria for security decision making