diff options
author | Drew DeVault <sir@cmpwn.com> | 2016-12-02 10:05:43 -0500 |
---|---|---|
committer | Drew DeVault <sir@cmpwn.com> | 2016-12-02 10:05:43 -0500 |
commit | 3dbeb9c35cd3cd71b318370b776bdaa00436a356 (patch) | |
tree | 9dc5d18e412e8666425f74b5b43e28b2f5271812 /sway | |
parent | Unset LD_PRELOAD on startup (before dropping root) (diff) | |
download | sway-3dbeb9c35cd3cd71b318370b776bdaa00436a356.tar.gz sway-3dbeb9c35cd3cd71b318370b776bdaa00436a356.tar.zst sway-3dbeb9c35cd3cd71b318370b776bdaa00436a356.zip |
Add sway-security(7)
Diffstat (limited to 'sway')
-rw-r--r-- | sway/CMakeLists.txt | 1 | ||||
-rw-r--r-- | sway/sway-security.7.txt | 229 |
2 files changed, 230 insertions, 0 deletions
diff --git a/sway/CMakeLists.txt b/sway/CMakeLists.txt index 9349c30d..89388220 100644 --- a/sway/CMakeLists.txt +++ b/sway/CMakeLists.txt | |||
@@ -73,3 +73,4 @@ add_manpage(sway 1) | |||
73 | add_manpage(sway 5) | 73 | add_manpage(sway 5) |
74 | add_manpage(sway-input 5) | 74 | add_manpage(sway-input 5) |
75 | add_manpage(sway-bar 5) | 75 | add_manpage(sway-bar 5) |
76 | add_manpage(sway-security 7) | ||
diff --git a/sway/sway-security.7.txt b/sway/sway-security.7.txt new file mode 100644 index 00000000..f3d4a229 --- /dev/null +++ b/sway/sway-security.7.txt | |||
@@ -0,0 +1,229 @@ | |||
1 | ///// | ||
2 | vim:set ts=4 sw=4 tw=82 noet: | ||
3 | ///// | ||
4 | sway-security (7) | ||
5 | ================= | ||
6 | |||
7 | Name | ||
8 | ---- | ||
9 | sway-security - Guidelines for securing your sway install | ||
10 | |||
11 | Security Overview | ||
12 | ----------------- | ||
13 | |||
14 | **Sway is NOT secure**. We are working on it but do not trust that we have it all | ||
15 | figured out yet. The following man page is provisional. | ||
16 | |||
17 | Securing sway requires careful configuration of your environment, the sort that's | ||
18 | usually best suited to a distro maintainer who wants to ship a secure sway | ||
19 | environment in their distro. Sway provides a number of means of securing it but | ||
20 | you must make a few changes external to sway first. | ||
21 | |||
22 | Configuration security | ||
23 | ---------------------- | ||
24 | |||
25 | Many of Sway's security features are configurable. It's important that a possibly | ||
26 | untrusted program is not able to edit this. Security rules are kept in | ||
27 | _/etc/sway/config.d/security_ (usually), which should only be writable by root. | ||
28 | However, configuration of security rules is not limited to this file - any config | ||
29 | file that sway loads (including i.e. _~/.config/sway/config_) should not be editable | ||
30 | by the user you intend to run programs as. One simple strategy is to use | ||
31 | /etc/sway/config instead of a config file in your home directory, but that doesn't | ||
32 | work well for multi-user systems. A more robust strategy is to run untrusted | ||
33 | programs as another user, or in a sandbox. Configuring this is up to you. | ||
34 | |||
35 | Note that _/etc/sway/config.d/*_ must be included explicitly from your config file. | ||
36 | This is done by default in /etc/sway/config but you must check your own config if | ||
37 | you choose to place it in other locations. | ||
38 | |||
39 | Environment security | ||
40 | -------------------- | ||
41 | |||
42 | LD_PRELOAD is a mechanism designed by GNU for the purpose of ruining the security | ||
43 | of your system. One of the many ways LD_PRELOAD kills security is by making | ||
44 | Wayland keyloggers possible. | ||
45 | |||
46 | There are a number of strategies for dealing with this but they all suck a little. | ||
47 | In order of most practical to least practical: | ||
48 | |||
49 | 1. Only run important programs via exec. Sway's exec command will ensure that | ||
50 | LD_PRELOAD is unset when running programs. | ||
51 | |||
52 | 2. Remove LD_PRELOAD support from your dynamic loader (requires patching libc). | ||
53 | This may break programs that rely on LD_PRELOAD for legitimate functionality, | ||
54 | but this is the most effective solution. | ||
55 | |||
56 | 3. Use static linking for important programs. Of course statically linked programs | ||
57 | are unaffected by the security dumpster fire that is dynamic linking. | ||
58 | |||
59 | Note that should you choose method 1, you MUST ensure that sway itself isn't | ||
60 | compromised by LD_PRELOAD. It probably isn't, but you can be sure by setting | ||
61 | /usr/bin/sway to a+s (setuid), which will instruct the dynamic linker not to | ||
62 | permit LD_PRELOAD for it (and will also run it as root, which sway will shortly | ||
63 | drop). You could also statically link sway itself. | ||
64 | |||
65 | Read your log | ||
66 | ------------- | ||
67 | |||
68 | Sway does sanity checks and prints big red warnings to stderr if they fail. Read | ||
69 | them. | ||
70 | |||
71 | Feature policies | ||
72 | ---------------- | ||
73 | |||
74 | Certain sway features are security sensitive and may be configured with security | ||
75 | policies. These features are: | ||
76 | |||
77 | **background**:: | ||
78 | Permission for a program to become the background. | ||
79 | |||
80 | **fullscreen**:: | ||
81 | Permission to become fullscreen. Note that users can always make a window | ||
82 | fullscreen themselves with the fullscreen command. | ||
83 | |||
84 | **keyboard**:: | ||
85 | Permission to receive keyboard events. | ||
86 | |||
87 | **lock**:: | ||
88 | Permission for a program to act as a screen locker. This involves becoming | ||
89 | fullscreen (on all outputs) and accepting all keyboard and mouse input for the | ||
90 | duration of the process. | ||
91 | |||
92 | **mouse**:: | ||
93 | Permission to receive mouse events. | ||
94 | |||
95 | **panel**:: | ||
96 | Permission for a program to stick its windows to the sides of the screen. | ||
97 | |||
98 | **screenshot**:: | ||
99 | Permission to take screenshots or record the screen. | ||
100 | |||
101 | By default, all programs are granted **fullscreen**, **keyboard**, and **mouse** | ||
102 | permissions. You can use the following config commands to control a program's | ||
103 | access: | ||
104 | |||
105 | **permit** <executable> <features...>:: | ||
106 | Permits <executable> to use <features> (each feature seperated by a space). | ||
107 | <executable> may be * to affect the default policy. | ||
108 | |||
109 | **reject** <executable> <features...>:: | ||
110 | Disallows <executable> from using <features> (each feature seperated by a space). | ||
111 | <executable> may be * to affect the default policy. | ||
112 | |||
113 | Note that policy enforcement requires procfs to be mounted at /proc and the sway | ||
114 | process to be able to access _/proc/[pid]/exe_ (see **procfs(5)** for details on | ||
115 | this access - setcap cap_sys_ptrace=eip /usr/bin/sway should do the trick). If | ||
116 | sway is unable to read _/proc/[pid]/exe_, it will apply the default policy. | ||
117 | |||
118 | Command policies | ||
119 | ---------------- | ||
120 | |||
121 | You can also control the context from which a command may execute. The different | ||
122 | contexts you can control are: | ||
123 | |||
124 | **config**:: | ||
125 | Can be run from your config file. | ||
126 | |||
127 | **binding**:: | ||
128 | Can be run from bindsym or bindcode commands. | ||
129 | |||
130 | **ipc**:: | ||
131 | Can be run by IPC clients. | ||
132 | |||
133 | **criteria**:: | ||
134 | Can be run when evaluating window criteria. | ||
135 | |||
136 | By default a command is allowed to execute in any context. To configure this, open | ||
137 | a commands block and fill it with policies: | ||
138 | |||
139 | commands { | ||
140 | <name> <contexts...> | ||
141 | ... | ||
142 | } | ||
143 | |||
144 | For example, you could do this to limit the use of the focus command to just | ||
145 | binding and critiera: | ||
146 | |||
147 | commands { | ||
148 | focus binding criteria | ||
149 | } | ||
150 | |||
151 | IPC policies | ||
152 | ------------ | ||
153 | |||
154 | By default all programs can connect to IPC for backwards compatability with i3. | ||
155 | However, you can whitelist IPC access like so: | ||
156 | |||
157 | reject * ipc | ||
158 | permit /usr/bin/swaybar ipc | ||
159 | permit /usr/bin/swaygrab ipc | ||
160 | # etc | ||
161 | |||
162 | Note that it's suggested you do not enable swaymsg to access IPC if you intend to | ||
163 | secure your IPC socket, because any program could just run swaymsg itself instead | ||
164 | of connecting to IPC directly. | ||
165 | |||
166 | You can also configure which features of IPC are available with an IPC block: | ||
167 | |||
168 | ipc { | ||
169 | ... | ||
170 | } | ||
171 | |||
172 | The following commands are available within this block: | ||
173 | |||
174 | **bar-config** <enabled|disabled>:: | ||
175 | Controls GET_BAR_CONFIG (required for swaybar to work at all). | ||
176 | |||
177 | **command** <enabled|disabled>:: | ||
178 | Controls executing sway commands via IPC. | ||
179 | |||
180 | **inputs** <enabled|disabled>:: | ||
181 | Controls GET_INPUTS (input device information). | ||
182 | |||
183 | **marks** <enabled|disabled>:: | ||
184 | Controls GET_MARKS. | ||
185 | |||
186 | **outputs** <enabled|disabled>:: | ||
187 | Controls GET_OUTPUTS. | ||
188 | |||
189 | **tree** <enabled|disabled>:: | ||
190 | Controls GET_TREE. | ||
191 | |||
192 | **workspaces** <enabled|disabled>:: | ||
193 | Controls GET_WORKSPACES. | ||
194 | |||
195 | You can also control which IPC events can be raised with an events block: | ||
196 | |||
197 | ipc { | ||
198 | events { | ||
199 | ... | ||
200 | } | ||
201 | } | ||
202 | |||
203 | The following commands are vaild within an ipc events block: | ||
204 | |||
205 | **binding** <enabled|disabled>:: | ||
206 | Controls keybinding notifications (disabled by default). | ||
207 | |||
208 | **input** <enabled|disabled>:: | ||
209 | Controls input device hotplugging notifications. | ||
210 | |||
211 | **mode** <enabled|disabled>:: | ||
212 | Controls output hotplugging notifications. | ||
213 | |||
214 | **output** <enabled|disabled>:: | ||
215 | Controls output hotplugging notifications. | ||
216 | |||
217 | **window** <enabled|disabled>:: | ||
218 | Controls window event notifications. | ||
219 | |||
220 | **workspace** <enabled|disabled>:: | ||
221 | Controls workspace notifications. | ||
222 | |||
223 | Disabling some of these may cause swaybar to behave incorrectly. | ||
224 | |||
225 | Authors | ||
226 | ------- | ||
227 | Maintained by Drew DeVault <sir@cmpwn.com>, who is assisted by other open | ||
228 | source contributors. For more information about sway development, see | ||
229 | <https://github.com/SirCmpwn/sway>. | ||