1SWAY-SECURITY(7) SWAY-SECURITY(7)
2
6 sway-security - Guidelines for securing your sway install
7
9 Sway is NOT secure. We are working on it but do not trust that we have
10 it all figured out yet. The following man page is provisional.
11 Securing sway requires careful configuration of your environment, the
13 sort that’s usually best suited to a distribution maintainer who wants
14 to ship a secure sway environment in their distribution. Sway provides
15 a number of means of securing it but you must make a few changes
16 external to sway first.
17 Configuration of security features is limited to files in the security
19 directory (this is likely /etc/sway/security.d/*, but depends on your
20 installation prefix). Files in this directory must be owned by
21 root:root and chmod 644 or 444. The default security configuration is
22 installed to /etc/sway/security.d/00-defaults, and should not be
23 modified - it will be updated with the latest recommended security
24 defaults between releases. To override the defaults, you should add
25 more files to this directory.
26
28 LD_PRELOAD is a mechanism designed to ruin the security of your system.
29 There are a number of strategies for dealing with this, but they all
30 suck a little. In order of most practical to least practical:
31 1. Only run important programs via exec. Sway’s exec command will
33 ensure that LD_PRELOAD is unset when running programs.
34 2. Remove LD_PRELOAD support from your dynamic loader (requires
36 patching libc). This may break programs that rely on LD_PRELOAD for
37 legitimate functionality, but this is the most effective solution.
38 3. Use static linking for important programs. Of course statically
40 linked programs are unaffected by the dynamic linking security
41 dumpster fire.
42 Note that should you choose method 1, you MUST ensure that sway itself
44 isn’t compromised by LD_PRELOAD. It probably isn’t, but you can be sure
45 by setting /usr/bin/sway to a+s (setuid), which will instruct the
46 dynamic linker not to permit LD_PRELOAD for it (and will also run it as
47 root, which sway will shortly drop). You could also statically link
48 sway itself.
49 Note that LD_LIBRARY_PATH has all of these problems, and the same
51 solutions.
52
54 Sway does sanity checks and prints big red warnings to stderr if they
55 fail. Read them.
56
58 Certain sway features are security sensitive and may be configured with
59 security policies. These features are:
60 background
62 Permission for a program to become the background.
63 fullscreen
65 Permission to become fullscreen. Note that users can always make a
66 window fullscreen themselves with the fullscreen command.
67 ipc
69 Permission to connect to sway’s IPC socket.
70 keyboard
72 Permission to receive keyboard events (only while they are
73 focused).
74 lock
76 Permission for a program to act as a screen locker. This involves
77 becoming fullscreen (on all outputs) and receiving all keyboard and
78 mouse input for the duration of the process.
79 mouse
81 Permission to receive mouse events (only while the mouse is over
82 them).
83 panel
85 Permission for a program to stick its windows to the sides of the
86 screen.
87 screenshot
89 Permission to take screenshots or record the screen.
90 By default, no permissions are granted (though saner defaults are
92 provided in /etc/sway/security.d/00-defaults). You can use the
93 following configuration options to control a program’s access:
94 permit <executable> <features...>
96 Permits <executable> to use <features> (each feature separated by a
97 space). <executable> may be * to affect the default policy, or the
98 full path to the executable file.
99 reject <executable> <features...>
101 Disallows <executable> from using <features> (each feature
102 separated by a space). <executable> may be * to affect the default
103 policy, or the full path to the executable file.
104 Note that policy enforcement requires procfs to be mounted at /proc and
106 the sway process to be able to access /proc/[pid]/exe (see procfs(5)
107 for details on this access - setcap cap_sys_ptrace=eip /usr/bin/sway
108 should do the trick). If sway is unable to read /proc/[pid]/exe, it
109 will apply the default policy.
110 To work correctly, sway’s own programs require the following
112 permissions:
113 · swaybg: background
115 · swaylock: lock, keyboard
117 · swaybar: panel, mouse, ipc
119 · swaygrab: screenshot, ipc
121 When you first declare a policy for an executable, it will inherit the
123 default policy. Further changes to the default policy will not
124 retroactively affect which permissions an earlier policy inherits. You
125 must explicitly reject any features from the default policy that you do
126 not want an executable to receive permission for.
127
129 You can also control the context from which a command may execute. The
130 different contexts you can control are:
131 config
133 Can be run from your config file.
134 binding
136 Can be run from bindsym or bindcode commands.
137 ipc
139 Can be run by IPC clients.
140 criteria
142 Can be run when evaluating window criteria.
143 all
145 Shorthand for granting permission in all contexts.
146 By default a command is allowed to execute in any context. To configure
148 this, open a commands block and fill it with policies:
149 commands {
151 <name> <contexts...>
152 ...
153 }
154 For example, you could do this to limit the use of the focus command to
156 just binding and criteria:
157 commands {
159 focus binding criteria
160 }
161 Setting a command policy overwrites any previous policy that was in
163 place.
164
166 Disabling IPC access via swaymsg is encouraged if you intend to secure
167 the IPC socket, because any program that can execute swaymsg could
168 circumvent its own security policy by simply invoking swaymsg.
169 You can configure which features of IPC are available for particular
171 clients:
172 ipc <executable> {
174 ...
175 }
176 You may use * for <executable> to configure the default policy for all
178 clients. Configuring IPC policies for specific executables is not
179 supported on FreeBSD, and the default policy will be applied to all IPC
180 connections.
181 The following commands are available within this block:
183 bar-config <enabled|disabled>
185 Controls GET_BAR_CONFIG (required for swaybar to work at all).
186 command <enabled|disabled>
188 Controls executing sway commands via IPC.
189 inputs <enabled|disabled>
191 Controls GET_INPUTS (input device information).
192 marks <enabled|disabled>
194 Controls GET_MARKS.
195 outputs <enabled|disabled>
197 Controls GET_OUTPUTS.
198 tree <enabled|disabled>
200 Controls GET_TREE.
201 workspaces <enabled|disabled>
203 Controls GET_WORKSPACES.
204 You can also control which IPC events can be raised with an events
206 block:
207 ipc <executable> {
209 events {
210 ...
211 }
212 }
213 The following commands are valid within an IPC events block:
215 binding <enabled|disabled>
217 Controls keybinding notifications (disabled by default).
218 input <enabled|disabled>
220 Controls input device hotplugging notifications.
221 mode <enabled|disabled>
223 Controls output hotplugging notifications.
224 output <enabled|disabled>
226 Controls output hotplugging notifications.
227 window <enabled|disabled>
229 Controls window event notifications.
230 workspace <enabled|disabled>
232 Controls workspace notifications.
233 In each of these blocks, you may use * (as in "* enabled" or "*
235 disabled") to control access to every feature at once.
236
238 Maintained by Drew DeVault <sir@cmpwn.com>, who is assisted by other
239 open source contributors. For more information about sway development,
240 see https://github.com/swaywm/sway.
241 07/26/2018 SWAY-SECURITY(7)