ffs ssl -- wingologrelated17 October
| )I just set up SSL on my web site.
Everything can be had via , and things appear to work.
However the process of transitioning even a simple web site to SSL is so clownshoes bad that it's amazing anyone ever does it.
So here's an incomplete list of things that can go wrong when you set up TLS on a web site.You search &how to set up https& on the Googs and click the first link.
It takes you
which tells you how to use StartSSL, which generates the key in your browser.
Whoops, your private key is now known to another server on this internet!
Why do people even recommend this?
It's the worst of the worst of .OK so you decide to pay for a certificate, assuming that will be better, and because who knows what's going on with StartSSL.
You've heard of RapidSSL so you go to .
WTF their price is 49 dollars for a stupid certificate?
Your domain name was only 10 dollars, and domain name resolution is an actual ongoing service, unlike certificate issuance that just happens one time.
You can't believe it so you click through to the prices to see, and you get this:
WhattttttttttOK so I'm using
on Debian and I think that uses the system root CA list which is different from what Chrome or Firefox do but Jesus this is shaking my faith in the internet if I can't connect to an SSL certificate provider over SSL.You remember hearing something on Twitter about cheaper certs, and oh ho ho, it's , not just RapidSSL.
It turns out Geotrust and RapidSSL and Verisign are all owned by Symantec anyway.
So you go and you pay.
Paying is the first thing you have to do on rapidsslonline, before anything else happens.
Welp, cross your fingers and take out your credit card, cause SSLanta Clause is coming to town.Recall, distantly, that SSL has private keys and public keys.
To create an SSL certificate you have to generate a key on your local machine, which is your private key.
That key shouldn't leave your control -- that's why the DigitalOcean page is so bogus.
The certification authority (CA) then needs to receive your public key and then return it signed.
You don't know how to do this, because who does?
So you Google and .
Whoops!Hey neat it didn't delete your home directory, cool.
Let's assume that your local machine isn't rooted and that your server isn't rooted and that your hosting provider isn't rooted, because that would invalidate everything.
Oh what so the NSA and the five eyes have an ?
Um, well, water under the bridge I guess.
Let's make a key.
You google &generate ssl key& and this is the first result.
# openssl genrsa -des3 -out foo.key 1024
Whoops, you just made a 1024-bit key!
I don't know if those are even accepted by CAs any more.
Happily if you leave off the 1024, it defaults to 2048 bits, which I guess is good.Also you just made a key with a password on it (that's the -des3 part).
This is eminently pointless.
In order to use your key, your web server will need the decrypted key, which means it will need the password to the key.
Adding a password does nothing for you.
If you lost your private key but you did have it password-protected, you're still toast: the available encryption cyphers are meant to be fast, not hard to break.
Any serious attacker will crack it directly.
And if they have access to your private key in the first place, encrypted or not, you're probably toast already.OK.
So let's say you make your key, and make what's called the &CRTCSR&, to ask for the cert.
# openssl req -new -key foo.key -out foo.csr
Now you're presented with a bunch of pointless-looking questions like your country code and your &organization&.
Seems pointless, right?
Well now I have to live with this confidence-inspiring dialog, because I left off the organization:
Don't mess up, kids!
But wait there's more.
You send in your CSR, finally figure out how to receive mail for hostmaster@yourdomain.org because that's what &verification& means (not, god forbid, control of the actual web site), and you get back a certificate.
Now the fun starts!How are you actually going to serve SSL?
Seems legit except if you do that you lose any kind of indication about what IP is connecting to your HTTP server.
You can use a more HTTP-oriented terminator like
but then you have to mess with X-Forwarded-For headers and you only get them on the first request of a connection.
You could just enable mod_ssl on your Apache, but that code is terrifying, and do you really want to be running Apache anyway?In my case I ended up switching over to nginx, which has a startlingly underspecified configuration language, but for which the Debian defaults are actually not bad.
So you uncomment that part of the configuration, cross your fingers, Google a bit to remind yourself how systemd works, and restart the web server.
Haich Tee Tee Pee Ess ahoy!
But did you remember to disable the NULL authentication method?
How can you test it?
What about the NULL encryption method?
These are actual things that are configured into OpenSSL, and specified by standards.
(What is the use of a secure communications standard that does not provide any guarantee worth speaking of?)
So you google, , turn them off.
Great, now you are a dilettante tweaking your encryption parameters, I hope you feel like a fool because I sure do.Except !
So you better make sure you disable RC4, which incidentally is exactly .OK, so you took your certificate that you got from the CA and your private key and mashed them into place and it seems the web browser works.
Thing is though, the key that signs your certificate is possibly not in the actual root set of signing keys that browsers use to verify the key validity.
If you put just your key on the web site without the &intermediate CA&, then things probably work but browsers will make an additional request to get the intermediate CA's key, slowing down everything.
So you have to concatenate the text files with your key and the one with the intermediate CA's key.
They look the same, just a bunch of numbers, but don't get them in the wrong order because apparently the internet says that won't work!But don't put in too many keys either!
In this image we have a cert for < with one intermediate CA:And here is the same but with an a different root that signed the GeoTrust Global CA certificate.
Apparently there was a time in which the GeoTrust cert hadn't been added to all of the root sets yet, and it might not hurt to include them all:Thing is, the first one shows up &green& in Chrome (yay), but the second one shows problems (&outdated security settings& etc etc etc).
Because the link from Equifax to Geotrust uses a .
Good times?
last night was doing some basic science on the internet to bring you these results.)Or is Chrome denying you the green because it was RapidSSL that signed your certificate with SHA-1 and not SHA-256?
It won't tell you!
So you Google and apply snakeoil and beg your CA to reissue your cert, hopefully they don't charge for that, and eventually all is well.
Chrome gives you the green.Or does it?
Probably not, if you're switching from a web site that is also available over HTTP.
Probably you have some images or CSS or Javascript that's being loaded over HTTP.
You fix your web site to have scheme-relative URLs (like //wingolog.org/ instead of http://wingolog.org/), and make sure that your software can deal with it all (I had to patch Guile :P).
Update all the old blog posts!
Edit all the HTMLs!
And finally, green!
You're golden!Or not!
Also, TLSv1.0, which is actually greater than SSLv3 for no good reason, and then TLS1.1 also has problems, so you better stick with just TLSv1.2.
Except, except, older Android phones don't support TLSv1.2, and neither does the Googlebot, so .
So you upgrade your phone because that's a thing you want to do with your evenings, and send snarky tweets into the ether about scumbag google wanting to promote HTTPS but not supporting the latest TLS version.So finally, finally, you have a web site that offers HTTPS and HTTP access.
You're good right?
Except no!
(Catching on to the pattern?)
Because what happens is that people just type in web addresses to their URL bars like && and leave off the HTTP, because why type those stupid things.
So you arrange for
to redirect
for users that have visited the HTTPS site.
Except no!
.The &solution& for this is called HTTP Strict Transport Security, or HSTS.
Once a visitor visits your HTTPS site, the server sends a response that tells the browser never to fetch HTTP from this site.
Except that doesn't work the first time you go to a web site!
So if you're Google, you friggin .
EXCEPT EVEN THEN .And what if instead they go to < instead of the
that you configured?
Well, better enable HSTS for the whole site, but to do anything useful with such a web request you'll need a wildcard certificate to handle the multiple URLs, and those run like 150 bucks a year, for a one-bit change.
Or, just get more single-domain certs and tack them onto your cert, using the precision tool cat, but don't do too many, because if you do you will
and you'll have to wait for an ACK on your certificate before you can actually exchange keys.
Don't know what that means?
Better look it up and be an expert, or your wobsite's going to be slow!If your security goals are more modest, as they probably are, then you could get burned the other way: you could enable HSTS, something could go wrong with your site (an expired certificate perhaps), and then people couldn't access your site at all, even if they have no security needs, because HTTP is turned off.Now you start to add secure features to your web app, safe with the idea you have SSL.
But , otherwise they could be leaked in the clear, and better not forget that your website might also be served over HTTP.
And better check up on when your cert expires, and better have a plan for embedded browsers that don't have useful feedback to the user about certificate status, and what about your CA's audit trail, and better stay on top of the new developments in security!
It's a wonder anything works.
Indeed I wonder if anything does.Leave a Reply Name Mail (will not be published) Website What's your favorite number?systemd.exec·
systemd 221Namesystemd.exec — Execution environment configurationSynopsisservice.service,
socket.socket,
mount.mount,
swap.swapDescriptionUnit configuration files for services, sockets, mount
points, and swap devices share a subset of configuration options
which define the execution environment of spawned
processes.This man page lists the configuration options shared by
these four unit types. See
for the common options of all unit configuration files, and
for more information on the specific unit configuration files. The
execution specific configuration options are configured in the
[Service], [Socket], [Mount], or [Swap] sections, depending on the
unit type.OptionsWorkingDirectory=Takes an absolute directory path. Sets the
working directory for executed processes. If not set, defaults
to the root directory when systemd is running as a system
instance and the respective user's home directory if run as
user.RootDirectory=Takes an absolute directory path. Sets the
root directory for executed processes, with the
system call. If this is used, it must be ensured that the
process and all its auxiliary files are available in the
chroot() jail.User=, Group=Sets the Unix user or group that the processes
are executed as, respectively. Takes a single user or group
name or ID as argument. If no group is set, the default group
of the user is chosen.SupplementaryGroups=Sets the supplementary Unix groups the
processes are executed as. This takes a space-separated list
of group names or IDs. This option may be specified more than
once in which case all listed groups are set as supplementary
groups. When the empty string is assigned the list of
supplementary groups is reset, and all assignments prior to
this one will have no effect. In any way, this option does not
override, but extends the list of supplementary groups
configured in the system group database for the
user.Nice=Sets the default nice level (scheduling
priority) for executed processes. Takes an integer between -20
(highest priority) and 19 (lowest priority). See
for details.OOMScoreAdjust=Sets the adjustment level for the
Out-Of-Memory killer for executed processes. Takes an integer
between -1000 (to disable OOM killing for this process) and
1000 (to make killing of this process under memory pressure
very likely). See
for details.IOSchedulingClass=Sets the IO scheduling class for executed
processes. Takes an integer between 0 and 3 or one of the
strings none, realtime,
best-effort or idle. See
for details.IOSchedulingPriority=Sets the IO scheduling priority for executed
processes. Takes an integer between 0 (highest priority) and 7
(lowest priority). The available priorities depend on the
selected IO scheduling class (see above). See
for details.CPUSchedulingPolicy=Sets the CPU scheduling policy for executed
processes. Takes one of
for details.CPUSchedulingPriority=Sets the CPU scheduling priority for executed
processes. The available priority range depends on the
selected CPU scheduling policy (see above). For real-time
scheduling policies an integer between 1 (lowest priority) and
99 (highest priority) can be used. See
for details. CPUSchedulingResetOnFork=Takes a boolean argument. If true, elevated
CPU scheduling priorities and policies will be reset when the
executed processes fork, and can hence not leak into child
processes. See
for details. Defaults to false.CPUAffinity=Controls the CPU affinity of the executed
processes. Takes a space-separated list of CPU indices. This
option may be specified more than once in which case the
specified CPU affinity masks are merged. If the empty string
is assigned, the mask is reset, all assignments prior to this
will have no effect. See
for details.UMask=Controls the file mode creation mask. Takes an
access mode in octal notation. See
for details. Defaults to 0022.Environment=Sets environment variables for executed
processes. Takes a space-separated list of variable
assignments. This option may be specified more than once in
which case all listed variables will be set. If the same
variable is set twice, the later setting will override the
earlier setting. If the empty string is assigned to this
option, the list of environment variables is reset, all prior
assignments have no effect. Variable expansion is not
performed inside the strings, however, specifier expansion is
possible. The $ character has no special meaning. If you need
to assign a value containing spaces to a variable, use double
quotes (") for the assignment.Example:
Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"
gives three variables "VAR1",
"VAR2", "VAR3"
with the values "word1 word2",
"word3", "$word 5 6".
for details about environment variables.EnvironmentFile=Similar to Environment= but
reads the environment variables from a text file. The text
file should contain new-line-separated variable assignments.
Empty lines and
or # will be ignored,
which may be used for commenting. A line ending with a
backslash will be concatenated with the following one,
allowing multiline variable definitions. The parser strips
leading and trailing whitespace from the values of
assignments, unless you use double quotes (").The argument passed should be an absolute filename or
wildcard expression, optionally prefixed with
"-", which indicates that if the file does
not exist, it will not be read and no error or warning message
is logged. This option may be specified more than once in
which case all specified files are read. If the empty string
is assigned to this option, the list of file to read is reset,
all prior assignments have no effect.The files listed with this directive will be read
shortly before the process is executed (more specifically,
after all processes from a previous unit state terminated.
This means you can generate these files in one unit state, and
read it with this option in the next).Settings from these
files override settings made with
Environment=. If the same variable is set
twice from these files, the files will be read in the order
they are specified and the later setting will override the
earlier setting.StandardInput=Controls where file descriptor 0 (STDIN) of
the executed processes is connected to. Takes one of
tty-force,
tty-fail or
socket.If null is selected, standard input
will be connected to /dev/null, i.e. all
read attempts by the process will result in immediate
EOF.If tty is selected, standard input is
connected to a TTY (as configured by
TTYPath=, see below) and the executed
process becomes the controlling process of the terminal. If
the terminal is already being controlled by another process,
the executed process waits until the current controlling
process releases the terminal.tty-force is similar to
tty, but the executed process is forcefully
and immediately made the controlling process of the terminal,
potentially removing previous controlling processes from the
terminal.tty-fail is similar to
tty but if the terminal already has a
controlling process start-up of the executed process
fails.The socket option is only valid in
socket-activated services, and only when the socket
configuration file (see
for details) specifies a single socket only. If this option is
set, standard input will be connected to the socket the
service was activated from, which is primarily useful for
compatibility with daemons designed for use with the
traditional
daemon.This setting defaults to
null.StandardOutput=Controls where file descriptor 1 (STDOUT) of
the executed processes is connected to. Takes one of
journal+console,
syslog+console,
kmsg+console or
socket.inherit duplicates the file descriptor
of standard input for standard output.null connects standard output to
/dev/null, i.e. everything written to it
will be lost.tty connects standard output to a tty
(as configured via TTYPath=, see below). If
the TTY is used for output only, the executed process will not
become the controlling process of the terminal, and will not
fail or wait for other processes to release the
terminal.journal connects standard output with
the journal which is accessible via
Note that everything that is written to syslog or kmsg (see
below) is implicitly stored in the journal as well, the
specific two options listed below are hence supersets of this
one.syslog connects standard output to the
system syslog service, in addition to the journal. Note that
the journal daemon is usually configured to forward everything
it receives to syslog anyway, in which case this option is no
different from journal.kmsg connects standard output with the
kernel log buffer which is accessible via
in addition to the journal. The journal daemon might be
configured to send all logs to kmsg anyway, in which case this
option is no different from journal.journal+console,
syslog+console and
kmsg+console work in a similar way as the
three options above but copy the output to the system console
as well.socket connects standard output to a
socket acquired via socket activation. The semantics are
similar to the same option of
StandardInput=.This setting defaults to the value set with
DefaultStandardOutput= in
which defaults to journal.StandardError=Controls where file descriptor 2 (STDERR) of
the executed processes is connected to. The available options
are identical to those of StandardOutput=,
with one exception: if set to inherit the
file descriptor used for standard output is duplicated for
standard error. This setting defaults to the value set with
DefaultStandardError= in
which defaults to inherit.TTYPath=Sets the terminal device node to use if
standard input, output, or error are connected to a TTY (see
above). Defaults to
/dev/console.TTYReset=Reset the terminal device specified with
TTYPath= before and after execution.
Defaults to "no".TTYVHangup=Disconnect all clients which have opened the
terminal device specified with TTYPath=
before and after execution. Defaults to
"no".TTYVTDisallocate=If the terminal device specified with
TTYPath= is a virtual console terminal, try
to deallocate the TTY before and after execution. This ensures
that the screen and scrollback buffer is cleared. Defaults to
"no".SyslogIdentifier=Sets the process name to prefix log lines sent
to the logging system or the kernel log buffer with. If not
set, defaults to the process name of the executed process.
This option is only useful when
StandardOutput= or
StandardError= are set to
syslog, journal or
kmsg (or to the same settings in combination
with +console).SyslogFacility=Sets the syslog facility to use when logging
to syslog. One of kern,
user, mail,
daemon, auth,
syslog, lpr,
news, uucp,
cron, authpriv,
ftp, local0,
local1, local2,
local3, local4,
local5, local6 or
local7. See
for details. This option is only useful when
StandardOutput= or
StandardError= are set to
syslog. Defaults to
daemon.SyslogLevel=Default syslog level to use when logging to
syslog or the kernel log buffer. One of
debug. See
for details. This option is only useful when
StandardOutput= or
StandardError= are set to
syslog or kmsg. Note that
individual lines output by the daemon might be prefixed with a
different log level which can be used to override the default
log level specified here. The interpretation of these prefixes
may be disabled with SyslogLevelPrefix=,
see below. For details see
Defaults to
info.SyslogLevelPrefix=Takes a boolean argument. If true and
StandardOutput= or
StandardError= are set to
syslog, kmsg or
journal, log lines written by the executed
process that are prefixed with a log level will be passed on
to syslog with this log level set but the prefix removed. If
set to false, the interpretation of these prefixes is disabled
and the logged lines are passed on as-is. For details about
this prefixing see
Defaults to true.Sets the timer slack in nanoseconds for the
executed processes. The timer slack controls the accuracy of
wake-ups triggered by timers. See
for more information. Note that in contrast to most other time
span definitions this parameter takes an integer value in
nano-seconds if no unit is specified. The usual time units are
understood too.LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=These settings set both soft and hard limits
of various resources for executed processes. See
for details. Use the string infinity to
configure no limit on a specific resource.PAMName=Sets the PAM service name to set up a session
as. If set, the executed process will be registered as a PAM
session under the specified service name. This is only useful
in conjunction with the User= setting. If
not set, no PAM session will be opened for the executed
processes. See
for details.CapabilityBoundingSet=Controls which capabilities to include in the
capability bounding set for the executed process. See
for details. Takes a whitespace-separated list of capability
names as read by
e.g. CAP_SYS_ADMIN,
CAP_DAC_OVERRIDE,
CAP_SYS_PTRACE. Capabilities listed will
be included in the bounding set, all others are removed. If
the list of capabilities is prefixed with
"~", all but the listed capabilities will be
included, the effect of the assignment inverted. Note that
this option also affects the respective capabilities in the
effective, permitted and inheritable capability sets, on top
of what Capabilities= does. If this option
is not used, the capability bounding set is not modified on
process execution, hence no limits on the capabilities of the
process are enforced. This option may appear more than once in
which case the bounding sets are merged. If the empty string
is assigned to this option, the bounding set is reset to the
empty capability set, and all prior settings have no effect.
If set to "~" (without any further argument),
the bounding set is reset to the full set of available
capabilities, also undoing any previous
settings.SecureBits=Controls the secure bits set for the executed
process. Takes a space-separated combination of options from
the following list:
keep-caps,
keep-caps-locked,
no-setuid-fixup,
no-setuid-fixup-locked,
noroot, and
noroot-locked.
This option may appear more than once in which case the secure
bits are ORed. If the empty string is assigned to this option,
the bits are reset to 0. See
for details.Capabilities=Controls the
set for the executed process. Take a capability string
describing the effective, permitted and inherited capability
sets as documented in
Note that these capability sets are usually influenced (and
filtered) by the capabilities attached to the executed file.
Due to that CapabilityBoundingSet= is
probably a much more useful setting.ReadWriteDirectories=, ReadOnlyDirectories=, InaccessibleDirectories=Sets up a new file system namespace for
executed processes. These options may be used to limit access
a process might have to the main file system hierarchy. Each
setting takes a space-separated list of absolute directory
paths. Directories listed in
ReadWriteDirectories= are accessible from
within the namespace with the same access rights as from
outside. Directories listed in
ReadOnlyDirectories= are accessible for
reading only, writing will be refused even if the usual file
access controls would permit this. Directories listed in
InaccessibleDirectories= will be made
inaccessible for processes inside the namespace. Note that
restricting access with these options does not extend to
submounts of a directory that are created later on. These
options may be specified more than once in which case all
directories listed will have limited access from within the
namespace. If the empty string is assigned to this option, the
specific list is reset, and all prior assignments have no
effect.Paths in
ReadOnlyDirectories=
InaccessibleDirectories=
may be prefixed with
"-", in which case
they will be ignored when they do not
exist. Note that using this
setting will disconnect propagation of
mounts from the service to the host
(propagation in the opposite direction
continues to work). This means that
this setting may not be used for
services which shall be able to
install mount points in the main mount
namespace.PrivateTmp=Takes a boolean argument. If true, sets up a
new file system namespace for the executed processes and
mounts private /tmp and
/var/tmp directories inside it that is
not shared by processes outside of the namespace. This is
useful to secure access to temporary files of the process, but
makes sharing between processes via /tmp
or /var/tmp impossible. If this is
enabled, all temporary files created by a service in these
directories will be removed after the service is stopped.
Defaults to false. It is possible to run two or more units
within the same private /tmp and
/var/tmp namespace by using the
JoinsNamespaceOf= directive, see
for details. Note that using this setting will disconnect
propagation of mounts from the service to the host
(propagation in the opposite direction continues to work).
This means that this setting may not be used for services
which shall be able to install mount points in the main mount
namespace.PrivateDevices=Takes a boolean argument. If true, sets up a
new /dev namespace for the executed processes and only adds
API pseudo devices such as /dev/null,
/dev/zero or
/dev/random (as well as the pseudo TTY
subsystem) to it, but no physical devices such as
/dev/sda. This is useful to securely turn
off physical device access by the executed process. Defaults
to false. Enabling this option will also remove
CAP_MKNOD from the capability bounding
set for the unit (see above), and set
DevicePolicy=closed (see
for details). Note that using this setting will disconnect
propagation of mounts from the service to the host
(propagation in the opposite direction continues to work).
This means that this setting may not be used for services
which shall be able to install mount points in the main mount
namespace.PrivateNetwork=Takes a boolean argument. If true, sets up a
new network namespace for the executed processes and
configures only the loopback network device
"lo" inside it. No other network devices will
be available to the executed process. This is useful to
securely turn off network access by the executed process.
Defaults to false. It is possible to run two or more units
within the same private network namespace by using the
JoinsNamespaceOf= directive, see
for details. Note that this option will disconnect all socket
families from the host, this includes AF_NETLINK and AF_UNIX.
The latter has the effect that AF_UNIX sockets in the abstract
socket namespace will become unavailable to the processes
(however, those located in the file system will continue to be
accessible).ProtectSystem=Takes a boolean argument or
"full". If true, mounts the
/usr and /boot
directories read-only for processes invoked by this unit. If
set to "full", the /etc
directory is mounted read-only, too. This setting ensures that
any modification of the vendor supplied operating system (and
optionally its configuration) is prohibited for the service.
It is recommended to enable this setting for all long-running
services, unless they are involved with system updates or need
to modify the operating system in other ways. Note however
that processes retaining the CAP_SYS_ADMIN capability can undo
the effect of this setting. This setting is hence particularly
useful for daemons which have this capability removed, for
example with CapabilityBoundingSet=.
Defaults to off.ProtectHome=Takes a boolean argument or
"read-only". If true, the directories
/home and /run/user
are made inaccessible and empty for processes invoked by this
unit. If set to "read-only", the two
directories are made read-only instead. It is recommended to
enable this setting for all long-running services (in
particular network-facing ones), to ensure they cannot get
access to private user data, unless the services actually
require access to the user's private data. Note however that
processes retaining the CAP_SYS_ADMIN capability can undo the
effect of this setting. This setting is hence particularly
useful for daemons which have this capability removed, for
example with CapabilityBoundingSet=.
Defaults to off.MountFlags=Takes a mount propagation flag:
shared, slave or
private, which control whether mounts in the
file system namespace set up for this unit's processes will
receive or propagate mounts or unmounts. See
for details. Defaults to shared. Use
shared to ensure that mounts and unmounts are
propagated from the host to the container and vice versa. Use
slave to run processes so that none of their
mounts and unmounts will propagate to the host. Use
private to also ensure that no mounts and
unmounts from the host will propagate into the unit processes'
namespace. Note that slave means that file
systems mounted on the host might stay mounted continuously in
the unit's namespace, and thus keep the device busy. Note that
the file system namespace related options
(PrivateTmp=,
PrivateDevices=,
ProtectSystem=,
ProtectHome=,
ReadOnlyDirectories=,
InaccessibleDirectories= and
ReadWriteDirectories=) require that mount
and unmount propagation from the unit's file system namespace
is disabled, and hence downgrade shared to
slave. UtmpIdentifier=Takes a four character identifier string for
an utmp/wtmp entry for this service. This should only be set
for services such as getty implementations
where utmp/wtmp entries must be created and cleared before and
after execution. If the configured string is longer than four
characters, it is truncated and the terminal four characters
are used. This setting interprets %I style string
replacements. This setting is unset by default, i.e. no
utmp/wtmp entries are created or cleaned up for this
service.SELinuxContext=Set the SELinux security context of the
executed process. If set, this will override the automated
domain transition. However, the policy still needs to
authorize the transition. This directive is ignored if SELinux
is disabled. If prefixed by "-", all errors
will be ignored. See
for details.AppArmorProfile=Takes a profile name as argument. The process
executed by the unit will switch to this profile when started.
Profiles must already be loaded in the kernel, or the unit
will fail. This result in a non operation if AppArmor is not
enabled. If prefixed by "-", all errors will
be ignored. SmackProcessLabel=Takes a SMACK64 security
label as argument. The process executed by the unit will be
started under this label and SMACK will decide whether the
processes is allowed to run or not based on it. The process
will continue to run under the label specified here unless the
executable has its own SMACK64EXEC label, in
which case the process will transition to run under that
label. When not specified, the label that systemd is running
under is used. This directive is ignored if SMACK is
disabled.The value may be prefixed by "-", in
which case all errors will be ignored. An empty value may be
specified to unset previous assignments.IgnoreSIGPIPE=Takes a boolean argument. If true, causes
SIGPIPE to be ignored in the executed
process. Defaults to true because SIGPIPE
generally is useful only in shell pipelines.NoNewPrivileges=Takes a boolean argument. If true, ensures
that the service process and all its children can never gain
new privileges. This option is more powerful than the
respective secure bits flags (see above), as it also prohibits
UID changes of any kind. This is the simplest, most effective
way to ensure that a process and its children can never
elevate privileges again.SystemCallFilter=Takes a space-separated list of system call
names. If this setting is used, all system calls executed by
the unit processes except for the listed ones will result in
immediate process termination with the
SIGSYS signal (whitelisting). If the
first character of the list is "~", the
effect is inverted: only the listed system calls will result
in immediate process termination (blacklisting). If running in
user mode and this option is used,
NoNewPrivileges=yes is implied. This
feature makes use of the Secure Computing Mode 2 interfaces of
the kernel ('seccomp filtering') and is useful for enforcing a
minimal sandboxing environment. Note that the
rt_sigreturn,
sigreturn,
exit_group, exit
system calls are implicitly whitelisted and do not need to be
listed explicitly. This option may be specified more than once
in which case the filter masks are merged. If the empty string
is assigned, the filter is reset, all prior assignments will
have no effect.If you specify both types of this option (i.e.
whitelisting and blacklisting), the first encountered will
take precedence and will dictate the default action
(termination or approval of a system call). Then the next
occurrences of this option will add or delete the listed
system calls from the set of the filtered system calls,
depending of its type and the default action. (For example, if
you have started with a whitelisting of
read and write, and
right after it add a blacklisting of
write, then write
will be removed from the set.) SystemCallErrorNumber=Takes an "errno" error number
name to return when the system call filter configured with
SystemCallFilter= is triggered, instead of
terminating the process immediately. Takes an error name such
as EPERM, EACCES or
EUCLEAN. When this setting is not used,
or when the empty string is assigned, the process will be
terminated immediately when the filter is
triggered.SystemCallArchitectures=Takes a space separated list of architecture
identifiers to include in the system call filter. The known
architecture identifiers are x86,
x86-64, x32,
arm as well as the special identifier
native. Only system calls of the
specified architectures will be permitted to processes of this
unit. This is an effective way to disable compatibility with
non-native architectures for processes, for example to
prohibit execution of 32-bit x86 binaries on 64-bit x86-64
systems. The special native identifier
implicitly maps to the native architecture of the system (or
more strictly: to the architecture the system manager is
compiled for). If running in user mode and this option is
used, NoNewPrivileges=yes is implied. Note
that setting this option to a non-empty list implies that
native is included too. By default, this
option is set to the empty list, i.e. no architecture system
call filtering is applied.RestrictAddressFamilies=Restricts the set of socket address families
accessible to the processes of this unit. Takes a
space-separated list of address family names to whitelist,
AF_INET or
AF_INET6. When
prefixed with ~ the listed address
families will be applied as blacklist, otherwise as whitelist.
Note that this restricts access to the
system call only. Sockets passed into the process by other
means (for example, by using socket activation with socket
units, see
are unaffected. Also, sockets created with
socketpair() (which creates connected
AF_UNIX sockets only) are unaffected. Note that this option
has no effect on 32-bit x86 and is ignored (but works
correctly on x86-64). If running in user mode and this option
is used, NoNewPrivileges=yes is implied. By
default, no restriction applies, all address families are
accessible to processes. If assigned the empty string, any
previous list changes are undone.Use this option to limit exposure of processes to remote
systems, in particular via exotic network protocols. Note that
in most cases, the local AF_UNIX address
family should be included in the configured whitelist as it is
frequently used for local communication, including for
logging.Personality=Controls which kernel architecture
shall report, when invoked by unit processes. Takes one of
x86 and x86-64. This
is useful when running 32-bit services on a 64-bit host
system. If not specified, the personality is left unmodified
and thus reflects the personality of the host system's
kernel.Takes a list of directory names. If set, one
or more directories by the specified names will be created
below /run (for system services) or below
$XDG_RUNTIME_DIR (for user services) when
the unit is started, and removed when the unit is stopped. The
directories will have the access mode specified in
RuntimeDirectoryMode=, and will be owned by
the user and group specified in User= and
Group=. Use this to manage one or more
runtime directories of the unit and bind their lifetime to the
daemon runtime. The specified directory names must be
relative, and may not include a "/", i.e.
must refer to simple directories to create or remove. This is
particularly useful for unprivileged daemons that cannot
create runtime directories in /run due to
lack of privileges, and to make sure the runtime directory is
cleaned up automatically after use. For runtime directories
that require more complex or different configuration or
lifetime guarantees, please consider using
.Environment variables in spawned processesProcesses started by the system are executed in a clean
environment in which select variables listed below are set. System
processes started by systemd do not inherit variables from PID 1,
but processes started by user systemd instances inherit all
environment variables from the user systemd instance.
$PATHColon-separated list of directories to use
when launching executables. Systemd uses a fixed value of
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin.
$LANGLocale. Can be set in
or on the kernel command line (see
$USER, $LOGNAME, $HOME, $SHELLUser name (twice), home directory, and the
login shell. The variables are set for the units that have
User= set, which includes user
systemd instances. See
The directory for volatile state. Set for the
user systemd instance, and also in user
sessions. See
$XDG_SESSION_ID, $XDG_SEAT, $XDG_VTNRThe identifier of the session, the seat name,
and virtual terminal of the session. Set by
for login sessions. $XDG_SEAT and
$XDG_VTNR will only be set when attached to
a seat and a tty.$MAINPIDThe PID of the units main process if it is
known. This is only set for control processes as invoked by
ExecReload= and similar. $MANAGERPIDThe PID of the user systemd
instance, set for processes spawned by it. $LISTEN_FDS, $LISTEN_PIDInformation about file descriptors passed to a
service for socket activation. See
$TERMTerminal type, set only for units connected to
a terminal (StandardInput=tty,
StandardOutput=tty, or
StandardError=tty). See
Additional variables may be configured by the following
means: for processes spawned in specific units, use the
Environment= and
EnvironmentFile= to specify
variables globally, use DefaultEnvironment=
or the kernel option systemd.setenv= (see
Additional variables may also be set through PAM,
cf. .See Also}