SWAY-SECURITY(7)

NAME
sway-security - Guidelines for securing your sway install

SECURITY OVERVIEW

Sway is NOT secure. We are working on it but do not trust that we have it all figured out yet. The following man page is provisional.

Securing sway requires careful configuration of your environment, the sort that’s usually best suited to a distro maintainer who wants to ship a secure sway environment in their distro. Sway provides a number of means of securing it but you must make a few changes external to sway first.

Security-related configuration is only valid in /etc/sway/config (or whatever path is appropriate for your system).

ENVIRONMENT SECURITY

LD_PRELOAD is a mechanism designed to ruin the security of your system. There are a number of strategies for dealing with this but they all suck a little. In order of most practical to least practical:

    1. Only run important programs via exec. Sway’s exec command will ensure that LD_PRELOAD is unset when running programs.

    2. Remove LD_PRELOAD support from your dynamic loader (requires patching libc). This may break programs that rely on LD_PRELOAD for legitimate functionality, but this is the most effective solution.

    3. Use static linking for important programs. Of course statically linked programs are unaffected by the dynamic linking security dumpster fire.

Note that should you choose method 1, you MUST ensure that sway itself isn’t compromised by LD_PRELOAD. It probably isn’t, but you can be sure by setting /usr/bin/sway to a+s (setuid), which will instruct the dynamic linker not to permit LD_PRELOAD for it (and will also run it as root, which sway will shortly drop). You could also statically link sway itself.

Note that LD_LIBRARY_PATH has all of the same problems, and all of the same solutions.

READ YOUR LOG

Sway does sanity checks and prints big red warnings to stderr if they fail. Read them.

FEATURE POLICIES

Certain sway features are security sensitive and may be configured with security policies. These features are:

background
    Permission for a program to become the background.

fullscreen
    Permission to become fullscreen. Note that users can always make a window fullscreen themselves with the fullscreen command.

ipc
    Permission to connect to sway’s IPC socket.

keyboard
    Permission to receive keyboard events (only while they are focused).

lock
    Permission for a program to act as a screen locker. This involves becoming fullscreen (on all outputs) and receiving all keyboard and mouse input for the duration of the process.

mouse
    Permission to receive mouse events (only while the mouse is over them).

panel
    Permission for a program to stick its windows to the sides of the screen.

screenshot
    Permission to take screenshots or record the screen.

By default, no permissions are granted (though saner defaults are provided in /etc/sway/config.d/security). You can use the following config commands to control a program’s access:

permit <executable> <features...>
    Permits <executable> to use <features> (each feature seperated by a space). <executable> may be * to affect the default policy, or the full path to the executable file.

reject <executable> <features...>
    Disallows <executable> from using <features> (each feature seperated by a space). <executable> may be * to affect the default policy, or the full path to the executable file.

Note that policy enforcement requires procfs to be mounted at /proc and the sway process to be able to access /proc/[pid]/exe (see procfs(5) for details on this access - setcap cap_sys_ptrace=eip /usr/bin/sway should do the trick). If sway is unable to read /proc/[pid]/exe, it will apply the default policy.

To work correctly, sway’s own programs require the following permissions:

    • swaybg: background

    • swaylock: lock, keyboard

    • swaybar: panel, mouse, ipc

    • swaygrab: screenshot, ipc

When you first declare a policy for an executable, it will inherit the default policy. Further changes to the default policy will not retroactively affect which permissions an earlier policy inherits. You must explicitly reject any features from the default policy that you do not want an executable to receive permission for.

COMMAND POLICIES

You can also control the context from which a command may execute. The different contexts you can control are:

config
    Can be run from your config file.

binding
    Can be run from bindsym or bindcode commands.

ipc
    Can be run by IPC clients.

criteria
    Can be run when evaluating window criteria.

all
    Shorthand for granting permission in all contexts.

By default a command is allowed to execute in any context. To configure this, open a commands block and fill it with policies:

    commands {
            <name> <contexts...>
            ...
    }

For example, you could do this to limit the use of the focus command to just binding and critiera:

    commands {
            focus binding criteria
    }

Setting a command policy overwrites any previous policy that was in place.

IPC POLICIES

You may whitelist IPC access like so:

    permit /usr/bin/swaybar ipc
    permit /usr/bin/swaygrab ipc
    # etc

Note that it’s suggested you do not enable swaymsg to access IPC if you intend to secure your IPC socket, because any program could just run swaymsg itself instead of connecting to IPC directly.

You can also configure which features of IPC are available with an IPC block:

    ipc {
            ...
    }

The following commands are available within this block:

bar-config <enabled|disabled>
    Controls GET_BAR_CONFIG (required for swaybar to work at all).

command <enabled|disabled>
    Controls executing sway commands via IPC.

inputs <enabled|disabled>
    Controls GET_INPUTS (input device information).

marks <enabled|disabled>
    Controls GET_MARKS.

outputs <enabled|disabled>
    Controls GET_OUTPUTS.

tree <enabled|disabled>
    Controls GET_TREE.

workspaces <enabled|disabled>
    Controls GET_WORKSPACES.

You can also control which IPC events can be raised with an events block:

    ipc {
            events {
                    ...
            }
    }

The following commands are vaild within an ipc events block:

binding <enabled|disabled>
    Controls keybinding notifications (disabled by default).

input <enabled|disabled>
    Controls input device hotplugging notifications.

mode <enabled|disabled>
    Controls output hotplugging notifications.

output <enabled|disabled>
    Controls output hotplugging notifications.

window <enabled|disabled>
    Controls window event notifications.

workspace <enabled|disabled>
    Controls workspace notifications.

Disabling some of these may cause swaybar to behave incorrectly.

AUTHORS

Maintained by Drew DeVault <sir@cmpwn.com>, who is assisted by other open source contributors. For more information about sway development, see https://github.com/SirCmpwn/sway.