| Age | Commit message (Collapse) | Author |
|---|
|
Let's make this an excercise in dogfooding: let's turn on more security
features for all our long-running services.
Specifically:
- Turn on RestrictRealtime=yes for all of them
- Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of
them
- Turn on RestrictAddressFamilies= for all of them, but different sets of
address families for each
Also, always order settings in the unit files, that the various sandboxing
features are close together.
Add a couple of missing, older settings for a numbre of unit files.
Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively
turning of networking from udev rule commands. Since this might break stuff
(that is already broken I'd argue) this is documented in NEWS.
|
|
Take away kernel keyring access, CPU emulation system calls and various debug
system calls from the various daemons we have.
|
|
Add a line
SystemCallFilter=~@clock @module @mount @obsolete @raw-io ptrace
for daemons shipped by systemd. As an exception, systemd-timesyncd
needs @clock system calls and systemd-localed is not privileged.
ptrace(2) is blocked to prevent seccomp escapes.
|
|
Secure daemons shipped by systemd by enabling MemoryDenyWriteExecute.
Closes: #3459
|
|
Apparently, disk IO issues are more frequent than we hope, and 1min
waiting for disk IO happens, so let's increase the watchdog timeout a
bit, for all our services.
See #1353 for an example where this triggers.
|
|
On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau <michael.marineau@coreos.com> wrote:
> Currently systemd-timesyncd.service includes
> ConditionVirtualization=no, disabling it in both containers and
> virtual machines. Each VM platform tends to deal with or ignore the
> time problem in their own special ways, KVM/QEMU has the kernel time
> source kvm-clock, Xen has had different schemes over the years, VMware
> expects a userspace daemon sync the clock, and other platforms are
> content to drift with the wind as far as I can tell.
>
> I don't know of a robust way to know if a platform needs a little
> extra help from userspace to keep the clock sane or not but it seems
> generally safer to try than to risk drifting. Does anyone know of a
> reason to leave timesyncd off by default? Otherwise switching to
> ConditionVirtualization=!container should be reasonable.
|
|
This reverts commit 6a716208b346b742053cfd01e76f76fb27c4ea47.
Apparently this doesn't work.
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028212.html
|
|
No setuid programs are expected to be executed, so add
SecureBits=noroot noroot-locked
to unit files.
|
|
|
|
|
|
Only when necessary of course, nicely guarded with the new
ConditionNeedsUpdate= condition we added.
|
|
After all, that's what we document for time-sync.target in
systemd.special(5), hence let's follow our own suggestion.
|
|
also mounting /etc read-only
Also, rename ProtectedHome= to ProtectHome=, to simplify things a bit.
With this in place we now have two neat options ProtectSystem= and
ProtectHome= for protecting the OS itself (and optionally its
configuration), and for protecting the user's data.
|
|
ReadOnlySystem= uses fs namespaces to mount /usr and /boot read-only for
a service.
ProtectedHome= uses fs namespaces to mount /home and /run/user
inaccessible or read-only for a service.
This patch also enables these settings for all our long-running services.
Together they should be good building block for a minimal service
sandbox, removing the ability for services to modify the operating
system or access the user's private data.
|
|
Create initial stamp file with compiled-in time to prevent bootups
with clocks in the future from storing invalid timestamps.
At shutdown, only update the timestamp if we got an authoritative
time to store.
|
|
|
|
boot using this
This is useful to make sure the system clock stays monotonic even on
systems that lack an RTC.
Also, why we are at it, also use the systemd release time for bumping
the clock, since it's a slightly less bad than starting with jan 1st,
1970.
This also moves timesyncd into the early bootphase, in order to make
sure this initial bump is guaranteed to have finished by the time we
start real daemons which might write to the file systemd and thus
shouldn't leave 1970's timestamps all over the place...
|
|
|
|
with CAP_SYS_TIME)
|
|
|
|
This is needed for the network monitor to work (as it requires networkd to set up the correct directories first).
|
|
|
