itycodes
/
convince
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove sway-security(7)

Browse Source 
We will need to overhaul this for 1.0
master
Drew DeVault 8 years ago
parent d9a08b7a9d
commit 7a964651fb
1 changed files with 0 additions and 239 deletions
Show Stats Download Patch File Download Diff File

239
sway/sway-security.7.txt
Unescape View File

@ -1,239 +0,0 @@
/////
vim:set ts=4 sw=4 tw=82 noet:
/////
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 distribution maintainer who wants to ship a secure sway
environment in their distribution. Sway provides a number of means of securing it but
you must make a few changes external to sway first.
Configuration of security features is limited to files in the security directory
(this is likely /etc/sway/security.d/*, but depends on your installation prefix).
Files in this directory must be owned by root:root and chmod 644 or 444. The default
security configuration is installed to /etc/sway/security.d/00-defaults, and
should not be modified - it will be updated with the latest recommended security
defaults between releases. To override the defaults, you should add more files to
this directory.
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 these problems, and 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 configuration options to control
a program's access:
**permit** <executable> <features...>::
Permits <executable> to use <features> (each feature separated 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 separated 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 criteria:
commands {
focus binding criteria
}
Setting a command policy overwrites any previous policy that was in place.
IPC policies
------------
Disabling IPC access via swaymsg is encouraged if you intend to secure the IPC
socket, because any program that can execute swaymsg could circumvent its own
security policy by simply invoking swaymsg.
You can configure which features of IPC are available for particular clients:
ipc <executable> {
...
}
You may use * for <executable> to configure the default policy for all clients.
Configuring IPC policies for specific executables is not supported on FreeBSD, and
the default policy will be applied to all IPC connections.
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 <executable> {
events {
...
}
}
The following commands are valid 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.
In each of these blocks, you may use * (as in "* enabled" or "* disabled") to
control access to every feature at once.
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/swaywm/sway>.
Write Preview
Loading…
Cancel
Save