mirror of
https://github.com/swaywm/sway.git
synced 2024-11-10 12:33:50 +01:00
Remove sway-security(7)
We will need to overhaul this for 1.0
This commit is contained in:
Drew DeVault
parent
d9a08b7a9d
commit
7a964651fb
@ -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>.
|
||||
Loading…
Reference in New Issue
Block a user