Commit graph

456 commits

Author SHA1 Message Date
Jörg Thalheim c5bc77d151
Merge pull request #67748 from typetetris/yubico-local-auth
Yubico local auth
2019-09-24 03:31:39 +01:00
Franz Pletz 0dc4fe0a44
nixos/systemd: pick more upstream tmpfiles confs
In #68792 it was discovered that /dev/fuse doesn't have
wordl-read-writeable permissions anymore. The cause of this is that the
tmpfiles examples in systemd were reorganized and split into more files.
We thus lost some of the configuration we were depending on.

In this commit some of the new tmpfiles configuration that are
applicable to us are added which also makes wtmp/lastlog in the pam
module not necessary anymore.

Rationale for the new tmpfile configs:

  - `journal-nowcow.conf`: Contains chattr +C for journald logs which
  makes sense on copy-on-write filesystems like Btrfs. Other filesystems
  shouldn't do anything funny when that flag is set.

  - `static-nodes-permissions.conf`: Contains some permission overrides
  for some device nodes like audio, loop, tun, fuse and kvm.

  - `systemd-nspawn.conf`: Makes sure `/var/lib/machines` exists and old
  snapshots are properly removed.

  - `systemd-tmp.conf`: Removes systemd services related private tmp
  folders and temporary coredump files.

  - `var.conf`: Creates some useful directories in `/var` which we would
  create anyway at some point. Also includes
  `/var/log/{wtmp,btmp,lastlog}`.

Fixes #68792.
2019-09-23 15:23:31 +02:00
Eelco Dolstra b0ccd6dd16
Revert "nixos/doc: re-format"
This reverts commit ea6e8775bd. The new
format is not an improvement.
2019-09-19 19:17:30 +02:00
Jan Tojnar ea6e8775bd
nixos/doc: re-format 2019-09-18 22:13:35 +02:00
Robert Helgesson 866cc3e792 nixos/system-environment: introduce environment.profileRelativeSessionVariables
There is a need for having sessionVariables set relative to the Nix Profiles.
Such as in #68383.
2019-09-18 11:09:43 -04:00
Vladimír Čunát f21211ebfe
Merge branch 'master' into staging 2019-09-02 23:25:24 +02:00
Silvan Mosberger 478e7184f8
nixos/modules: Remove all usages of types.string
And replace them with a more appropriate type

Also fix up some minor module problems along the way
2019-08-31 18:19:00 +02:00
Aaron Andersen 58163e633b
Merge pull request #62954 from abbradar/auditd
auditd service: make more useful
2019-08-31 12:04:59 -04:00
Frederik Rietdijk ad1d58c622 Merge staging-next into staging 2019-08-31 10:04:20 +02:00
Eric Wolf edf538f7b9 yubico-pam: make local authentication possible
using challenge response

see https://developers.yubico.com/yubico-pam/Authentication_Using_Challenge-Response.html
2019-08-30 19:33:08 +02:00
Arian van Putten 604b7c139f Fix letsencrypt (#60219)
* nixos/acme: Fix ordering of cert requests

When subsequent certificates would be added, they would
not wake up nginx correctly due to target units only being triggered
once. We now added more fine-grained systemd dependencies to make sure
nginx always is aware of new certificates and doesn't restart too early
resulting in a crash.

Furthermore, the acme module has been refactored. Mostly to get
rid of the deprecated PermissionStartOnly systemd options which were
deprecated. Below is a summary of changes made.

* Use SERVICE_RESULT to determine status
This was added in systemd v232. we don't have to keep track
of the EXITCODE ourselves anymore.

* Add regression test for requesting mutliple domains

* Deprecate 'directory' option
We now use systemd's StateDirectory option to manage
create and permissions of the acme state directory.

* The webroot is created using a systemd.tmpfiles.rules rule
instead of the preStart script.

* Depend on certs directly

By getting rid of the target units, we make sure ordering
is correct in the case that you add new certs after already
having deployed some.

Reason it broke before:  acme-certificates.target would
be in active state, and if you then add a new cert, it
would still be active and hence nginx would restart
without even requesting a new cert. Not good!  We
make the dependencies more fine-grained now. this should fix that

* Remove activationDelay option

It complicated the code a lot, and is rather arbitrary. What if
your activation script takes more than activationDelay seconds?

Instead, one should use systemd dependencies to make sure some
action happens before setting the certificate live.

e.g. If you want to wait until your cert is published in DNS DANE /
TLSA, you could create a unit that blocks until it appears in DNS:

```
RequiredBy=acme-${cert}.service
After=acme-${cert}.service
ExecStart=publish-wait-for-dns-script
```
2019-08-29 16:32:59 +02:00
volth 35d68ef143 treewide: remove redundant quotes 2019-08-26 21:40:19 +00:00
Pierre Bourdon 67b7e70865
nixos/hardened: make pti=on overridable
Introduces a new security.forcePageTableIsolation option (default false
on !hardened, true on hardened) that forces pti=on.
2019-07-30 02:24:56 +02:00
Marek Mahut e72f25673d Renaming security.virtualization.flushL1DataCache to virtualisation
Fixes #65044
2019-07-19 15:49:37 +02:00
Nikolay Amiantov c3865335fb auditd service: make more useful
Enable kernel audit and install userspace utilities by default.
2019-06-10 18:55:11 +03:00
Eelco Dolstra de9e238469
FIx some malformed XML in option descriptions
E.g. these were using "<para>" at the *end* of a description. The real
WTF is that this is possible at all...
2019-05-13 09:15:17 +02:00
Joachim F 428ddf0619
Merge pull request #61306 from joachifm/feat/fix-apparmor-boot-linux_5_1
Fix apparmor boot on linux 5.1
2019-05-12 15:17:38 +00:00
Joachim Fasting 68f5d1fa4c
nixos/apparmor: ensure that apparmor is selected at boot
Otherwise we're subject to whatever defaults were selected at kernel build
time.

See also: https://github.com/NixOS/nixpkgs/issues/61145
2019-05-11 18:21:38 +02:00
Will Dietz e5d049e469 rngd: harden service config, from arch 2019-05-07 22:53:09 -05:00
Will Dietz b809071ffb rngd: add option to run w/debug flag
Added while testing if adding hardening
directives to the service blocked access
to various sources, might be useful in the future.
2019-05-06 23:44:38 -05:00
Joachim Fasting aa24c4e95b
nixos/apparmor: allow reloading profiles without losing confinement
Define ExecReload, otherwise reload implies stop followed by start, which
leaves existing processes in unconfined state [1].

[1]: https://gitlab.com/apparmor/apparmor/wikis/AppArmorInSystemd
2019-04-28 17:38:12 +02:00
Joachim Fasting f824dad19a
nixos/apparmor: order before sysinit.target
Otherwise, profiles may be loaded way too late in the init process.
2019-04-28 17:38:07 +02:00
Joachim Fasting b33da46a8e
nixos/hardened: split description of allowUserNamespaces into paras 2019-04-21 13:11:25 +02:00
Alexander Kahl 56bd0110e7 nixos/pam: Add GNOME keyring use_authtok directive to password group 2019-04-14 09:50:22 -04:00
Will Dietz c8a9c1c2b8 yubico-pam: add nixos integration 2019-03-31 12:04:35 -05:00
aszlig dcf40f7c24
Merge pull request #57519 (systemd-confinement)
Currently if you want to properly chroot a systemd service, you could do
it using BindReadOnlyPaths=/nix/store or use a separate derivation which
gathers the runtime closure of the service you want to chroot. The
former is the easier method and there is also a method directly offered
by systemd, called ProtectSystem, which still leaves the whole store
accessible. The latter however is a bit more involved, because you need
to bind-mount each store path of the runtime closure of the service you
want to chroot.

This can be achieved using pkgs.closureInfo and a small derivation that
packs everything into a systemd unit, which later can be added to
systemd.packages.

However, this process is a bit tedious, so the changes here implement
this in a more generic way.

Now if you want to chroot a systemd service, all you need to do is:

  {
    systemd.services.myservice = {
      description = "My Shiny Service";
      wantedBy = [ "multi-user.target" ];

      confinement.enable = true;
      serviceConfig.ExecStart = "${pkgs.myservice}/bin/myservice";
    };
  }

If more than the dependencies for the ExecStart* and ExecStop* (which
btw. also includes script and {pre,post}Start) need to be in the chroot,
it can be specified using the confinement.packages option. By default
(which uses the full-apivfs confinement mode), a user namespace is set
up as well and /proc, /sys and /dev are mounted appropriately.

In addition - and by default - a /bin/sh executable is provided, which
is useful for most programs that use the system() C library call to
execute commands via shell.

Unfortunately, there are a few limitations at the moment. The first
being that DynamicUser doesn't work in conjunction with tmpfs, because
systemd seems to ignore the TemporaryFileSystem option if DynamicUser is
enabled. I started implementing a workaround to do this, but I decided
to not include it as part of this pull request, because it needs a lot
more testing to ensure it's consistent with the behaviour without
DynamicUser.

The second limitation/issue is that RootDirectoryStartOnly doesn't work
right now, because it only affects the RootDirectory option and doesn't
include/exclude the individual bind mounts or the tmpfs.

A quirk we do have right now is that systemd tries to create a /usr
directory within the chroot, which subsequently fails. Fortunately, this
is just an ugly error and not a hard failure.

The changes also come with a changelog entry for NixOS 19.03, which is
why I asked for a vote of the NixOS 19.03 stable maintainers whether to
include it (I admit it's a bit late a few days before official release,
sorry for that):

  @samueldr:

    Via pull request comment[1]:

      +1 for backporting as this only enhances the feature set of nixos,
      and does not (at a glance) change existing behaviours.

    Via IRC:

      new feature: -1, tests +1, we're at zero, self-contained, with no
      global effects without actively using it, +1, I think it's good

  @lheckemann:

    Via pull request comment[2]:

      I'm neutral on backporting. On the one hand, as @samueldr says,
      this doesn't change any existing functionality. On the other hand,
      it's a new feature and we're well past the feature freeze, which
      AFAIU is intended so that new, potentially buggy features aren't
      introduced in the "stabilisation period". It is a cool feature
      though? :)

A few other people on IRC didn't have opposition either against late
inclusion into NixOS 19.03:

  @edolstra:  "I'm not against it"
  @Infinisil: "+1 from me as well"
  @grahamc:   "IMO its up to the RMs"

So that makes +1 from @samueldr, 0 from @lheckemann, 0 from @edolstra
and +1 from @Infinisil (even though he's not a release manager) and no
opposition from anyone, which is the reason why I'm merging this right
now.

I also would like to thank @Infinisil, @edolstra and @danbst for their
reviews.

[1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-477322127
[2]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-477548395
2019-03-29 04:37:53 +01:00
aszlig 52299bccf5
nixos/confinement: Use PrivateMounts option
So far we had MountFlags = "private", but as @Infinisil has correctly
noticed, there is a dedicated PrivateMounts option, which does exactly
that and is better integrated than providing raw mount flags.

When checking for the reason why I used MountFlags instead of
PrivateMounts, I found that at the time I wrote the initial version of
this module (Mar 12 06:15:58 2018 +0100) the PrivateMounts option didn't
exist yet and has been added to systemd in Jun 13 08:20:18 2018 +0200.

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-27 20:34:32 +01:00
aszlig 861a1cec60
nixos/confinement: Remove handling for StartOnly
Noted by @Infinisil on IRC:

   infinisil: Question regarding the confinement PR
   infinisil: On line 136 you do different things depending on
              RootDirectoryStartOnly
   infinisil: But on line 157 you have an assertion that disallows that
              option being true
   infinisil: Is there a reason behind this or am I missing something

I originally left this in so that once systemd supports that, we can
just flip a switch and remove the assertion and thus support
RootDirectoryStartOnly for our confinement module.

However, this doesn't seem to be on the roadmap for systemd in the
foreseeable future, so I'll just remove this, especially because it's
very easy to add it again, once it is supported.

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-27 20:22:37 +01:00
Alex Guzman 0c34b9fcf8
nixos/security: make duo support secure failure correctly
seems that this got broken when the config option was made to use enums. "secure" got replaced with "enum", which isn't a valid option for the failure mode.
2019-03-17 18:25:20 -07:00
aszlig d13ad389b4
nixos/confinement: Explicitly set serviceConfig
My implementation was relying on PrivateDevices, PrivateTmp,
PrivateUsers and others to be false by default if chroot-only mode is
used.

However there is an ongoing effort[1] to change these defaults, which
then will actually increase the attack surface in chroot-only mode,
because it is expected that there is no /dev, /sys or /proc.

If for example PrivateDevices is enabled by default, there suddenly will
be a mounted /dev in the chroot and we wouldn't detect it.

Fortunately, our tests cover that, but I'm preparing for this anyway so
that we have a smoother transition without the need to fix our
implementation again.

Thanks to @Infinisil for the heads-up.

[1]: https://github.com/NixOS/nixpkgs/issues/14645

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-15 04:13:01 +01:00
aszlig 9e9af4f9c0
nixos/confinement: Allow to include the full unit
From @edolstra at [1]:

  BTW we probably should take the closure of the whole unit rather than
  just the exec commands, to handle things like Environment variables.

With this commit, there is now a "fullUnit" option, which can be enabled
to include the full closure of the service unit into the chroot.

However, I did not enable this by default, because I do disagree here
and *especially* things like environment variables or environment files
shouldn't be in the closure of the chroot.

For example if you have something like:

  { pkgs, ... }:

  {
    systemd.services.foobar = {
      serviceConfig.EnvironmentFile = ${pkgs.writeText "secrets" ''
        user=admin
        password=abcdefg
      '';
    };
  }

We really do not want the *file* to end up in the chroot, but rather
just the environment variables to be exported.

Another thing is that this makes it less predictable what actually will
end up in the chroot, because we have a "globalEnvironment" option that
will get merged in as well, so users adding stuff to that option will
also make it available in confined units.

I also added a big fat warning about that in the description of the
fullUnit option.

[1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-472855704

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 20:04:33 +01:00
aszlig 46f7dd436f
nixos/confinement: Allow to configure /bin/sh
Another thing requested by @edolstra in [1]:

  We should not provide a different /bin/sh in the chroot, that's just
  asking for confusion and random shell script breakage. It should be
  the same shell (i.e. bash) as in a regular environment.

While I personally would even go as far to even have a very restricted
shell that is not even a shell and basically *only* allows "/bin/sh -c"
with only *very* minimal parsing of shell syntax, I do agree that people
expect /bin/sh to be bash (or the one configured by environment.binsh)
on NixOS.

So this should make both others and me happy in that I could just use
confinement.binSh = "${pkgs.dash}/bin/dash" for the services I confine.

[1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-472855704

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 19:14:05 +01:00
aszlig 0ba48f46da
nixos/systemd-chroot: Rename chroot to confinement
Quoting @edolstra from [1]:

  I don't really like the name "chroot", something like "confine[ment]"
  or "restrict" seems better. Conceptually we're not providing a
  completely different filesystem tree but a restricted view of the same
  tree.

I already used "confinement" as a sub-option and I do agree that
"chroot" sounds a bit too specific (especially because not *only* chroot
is involved).

So this changes the module name and its option to use "confinement"
instead of "chroot" and also renames the "chroot.confinement" to
"confinement.mode".

[1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-472855704

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 19:14:03 +01:00
aszlig ac64ce9945
nixos: Add 'chroot' options to systemd.services
Currently, if you want to properly chroot a systemd service, you could
do it using BindReadOnlyPaths=/nix/store (which is not what I'd call
"properly", because the whole store is still accessible) or use a
separate derivation that gathers the runtime closure of the service you
want to chroot. The former is the easier method and there is also a
method directly offered by systemd, called ProtectSystem, which still
leaves the whole store accessible. The latter however is a bit more
involved, because you need to bind-mount each store path of the runtime
closure of the service you want to chroot.

This can be achieved using pkgs.closureInfo and a small derivation that
packs everything into a systemd unit, which later can be added to
systemd.packages. That's also what I did several times[1][2] in the
past.

However, this process got a bit tedious, so I decided that it would be
generally useful for NixOS, so this very implementation was born.

Now if you want to chroot a systemd service, all you need to do is:

  {
    systemd.services.yourservice = {
      description = "My Shiny Service";
      wantedBy = [ "multi-user.target" ];

      chroot.enable = true;
      serviceConfig.ExecStart = "${pkgs.myservice}/bin/myservice";
    };
  }

If more than the dependencies for the ExecStart* and ExecStop* (which
btw. also includes "script" and {pre,post}Start) need to be in the
chroot, it can be specified using the chroot.packages option. By
default (which uses the "full-apivfs"[3] confinement mode), a user
namespace is set up as well and /proc, /sys and /dev are mounted
appropriately.

In addition - and by default - a /bin/sh executable is provided as well,
which is useful for most programs that use the system() C library call
to execute commands via shell. The shell providing /bin/sh is dash
instead of the default in NixOS (which is bash), because it's way more
lightweight and after all we're chrooting because we want to lower the
attack surface and it should be only used for "/bin/sh -c something".

Prior to submitting this here, I did a first implementation of this
outside[4] of nixpkgs, which duplicated the "pathSafeName" functionality
from systemd-lib.nix, just because it's only a single line.

However, I decided to just re-use the one from systemd here and
subsequently made it available when importing systemd-lib.nix, so that
the systemd-chroot implementation also benefits from fixes to that
functionality (which is now a proper function).

Unfortunately, we do have a few limitations as well. The first being
that DynamicUser doesn't work in conjunction with tmpfs, because it
already sets up a tmpfs in a different path and simply ignores the one
we define. We could probably solve this by detecting it and try to
bind-mount our paths to that different path whenever DynamicUser is
enabled.

The second limitation/issue is that RootDirectoryStartOnly doesn't work
right now, because it only affects the RootDirectory option and not the
individual bind mounts or our tmpfs. It would be helpful if systemd
would have a way to disable specific bind mounts as well or at least
have some way to ignore failures for the bind mounts/tmpfs setup.

Another quirk we do have right now is that systemd tries to create a
/usr directory within the chroot, which subsequently fails. Fortunately,
this is just an ugly error and not a hard failure.

[1]: https://github.com/headcounter/shabitica/blob/3bb01728a0237ad5e7/default.nix#L43-L62
[2]: https://github.com/aszlig/avonc/blob/dedf29e092481a33dc/nextcloud.nix#L103-L124
[3]: The reason this is called "full-apivfs" instead of just "full" is
     to make room for a *real* "full" confinement mode, which is more
     restrictive even.
[4]: https://github.com/aszlig/avonc/blob/92a20bece4df54625e/systemd-chroot.nix

Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 19:14:01 +01:00
Silvan Mosberger 02db11d369
Merge pull request #55792 from sdier/fix/pam-update
Allow duosec to be used in nixos as a pam module.
2019-02-25 01:38:51 +01:00
Scott Dier a3273e85e3 nixos/security: Fix pam configuration file generation. 2019-02-24 22:49:01 +00:00
Scott Dier 4e9ac79ef5 nixos/security: Allow configuration of pam for duosec. 2019-02-24 22:49:01 +00:00
Scott Dier 096e66a8ad nixos/security: Add duo-unix support to pam.
Also whitespace cleanup of surrounding code.
2019-02-24 22:48:56 +00:00
Symphorien Gibol a915b33315 nixos: add preferLocalBuild=true; on derivations for config files 2019-02-22 20:11:27 +01:00
Florian Klink d3c2ed21d0
Merge pull request #53762 from ju1m/nslcd
Improving integration of `nslcd`, PAM and `openldap`.
2019-01-30 19:34:40 +01:00
Wael Nasreddine f072cfe1eb
nixos/pam: refactor U2F, docs about u2f_keys path (#54756)
* change enableU2F option to u2f.* set
* add few u2f options (not all) to customize pam-u2f module
* document default u2f_keys locations

Co-authored-by: Tomasz Czyż <tomasz.czyz@gmail.com>
Co-authored-by: Arda Xi <arda@ardaxi.com>
2019-01-29 08:45:26 -08:00
Julien Moutinho 65cfba23af nixos/tests: test LDAP password changing through nslcd
NOTE: slapd.conf is deprecated, hence use cn=config.
2019-01-18 05:13:42 +01:00
Joachim Fasting ea4f371627
nixos/security/misc: expose SMT control option
For the hardened profile disable symmetric multi threading.  There seems to be
no *proven* method of exploiting cache sharing between threads on the same CPU
core, so this may be considered quite paranoid, considering the perf cost.
SMT can be controlled at runtime, however.  This is in keeping with OpenBSD
defaults.

TODO: since SMT is left to be controlled at runtime, changing the option
definition should take effect on system activation.  Write to
/sys/devices/system/cpu/smt/control
2018-12-27 15:00:49 +01:00
Joachim Fasting e9761fa327
nixos/security/misc: expose l1tf mitigation option
For the hardened profile enable flushing whenever the hypervisor enters the
guest, but otherwise leave at kernel default (conditional flushing as of
writing).
2018-12-27 15:00:48 +01:00
Joachim Fasting 84fb8820db
nixos/security/misc: factor out protectKernelImage
Introduces the option security.protectKernelImage that is intended to control
various mitigations to protect the integrity of the running kernel
image (i.e., prevent replacing it without rebooting).

This makes sense as a dedicated module as it is otherwise somewhat difficult
to override for hardened profile users who want e.g., hibernation to work.
2018-12-27 15:00:47 +01:00
Joachim Fasting 9db84f6fcd
nixos/security/misc: use mkMerge for easier extension 2018-12-27 15:00:46 +01:00
Florian Klink c6de45c0d7 config.security.googleOsLogin: add module
The OS Login package enables the following components:
AuthorizedKeysCommand to query valid SSH keys from the user's OS Login
profile during ssh authentication phase.
NSS Module to provide user and group information
PAM Module for the sshd service, providing authorization and
authentication support, allowing the system to use data stored in
Google Cloud IAM permissions to control both, the ability to log into
an instance, and to perform operations as root (sudo).
2018-12-21 17:52:37 +01:00
Florian Klink be5ad774bf security.pam.services.<name?>.: add googleOsLogin(AccountVerification|Authentication) 2018-12-21 17:52:37 +01:00
Florian Klink d180bf3862 security.pam: make pam_unix.so required, not sufficient
Having pam_unix set to "sufficient" means early-succeeding account
management group, as soon as pam_unix.so is succeeding.

This is not sufficient. For example, nixos modules might install nss
modules for user lookup, so pam_unix.so succeeds, and we end the stack
successfully, even though other pam account modules might want to do
more extensive checks.

Other distros seem to set pam_unix.so to 'required', so if there are
other pam modules in that management group, they get a chance to do some
validation too.

For SSSD, @PsyanticY already added a workaround knob in
https://github.com/NixOS/nixpkgs/pull/31969, while stating this should
be the default anyway.

I did some thinking in what could break - after this commit, we require
pam_unix to succeed, means we require `getent passwd $username` to
return something.
This is the case for all local users due to the passwd nss module, and
also the case for all modules installing their nss module to
nsswitch.conf - true for ldap (if not explicitly disabled) and sssd.

I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss
module loaded? Should the pam account module be placed before pam_unix?

We don't drop the `security.pam.services.<name?>.sssdStrictAccess`
option, as it's also used some lines below to tweak error behaviour
inside the pam sssd module itself (by changing it's 'control' field).

This is also required to get admin login for Google OS Login working
(#51566), as their pam_oslogin_admin accounts module takes care of sudo
configuration.
2018-12-21 15:31:07 +01:00
Gabriel Ebner 20078fd5b2 nixos/rngd: do not pass --version flag 2018-11-05 10:41:38 +01:00