AppArmor only requires a few patches to the 3.2 and 3.4 kernels in order
to work properly (with the minor catch grsecurity -stable includes the
3.2 patches.) This adds them to the kernel builds by default, removes
features.apparmor (since it's always true) and makes it the default MAC
system.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
systemd-tmpfiles-setup.service pulls in local-fs.target, which
interferes with NixOps' send-keys feature (since sshd.service depends
indirectly on sysinit.target). Since in NixOS we don't use
systemd-tmpfiles for creating files (that's done by activation scripts
and preStart scripts), it's not a problem to start it a bit later.
Backport: 14.04
kernels:
- longterm: 3.4.87 -> 3.4.88
- longterm: 3.10.37 -> 3.10.38
- stable: 3.13.10 -> 3.13.11
- stable: 3.14.1 -> 3.14.2
grsecurity:
- test: 3.0-3.14.1-201404241722 -> 3.0-3.14.2-201404270907
NOTE: technically the 3.13 stable kernel is now EOL. However, it will
become the long-term grsecurity stable kernel, and will have ongoing
support from Canonical.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Upstream has not been tagging new versions for a long time, but we need
compatibility with newer kernels. The 0.6.2 versions already have a bunch of
backported compatibility patches, but 3.14 kernels need even more.
Also, the git versions have fixed a bunch of crashes and other bugs, so perhaps
we should just bite the bullet and just use recent git versions (as sometimes
upstream recommends, when people run into bugs).
This adds a new "boot.zfs.useGit" boolean option, so that a user can
easily opt into using the git versions.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
This creates static device nodes such as /dev/fuse or
/dev/snd/seq. The kernel modules for these devices will be loaded on
demand when the device node is opened.
Note that systemd no longer depends on dbus, so we're rid of the
cyclic dependency problem between systemd and dbus.
This commit incorporates from wkennington's systemd branch
(203dcff45002a63f6be75c65f1017021318cc839,
1f842558a95947261ece66f707bfa24faf5a9d88).
(And update liburcu to 0.8.4 according to release notes for lttng 2.4.x.)
In addition to new features and bug fixes, version 2.4.x is needed to build
against Linux 3.12 (our new stable kernel).
This module implements a significant refactoring in grsecurity
configuration for NixOS, making it far more usable by default and much
easier to configure.
- New security.grsecurity NixOS attributes.
- All grsec kernels supported
- Allows default 'auto' grsec configuration, or custom config
- Supports custom kernel options through kernelExtraConfig
- Defaults to high-security - user must choose kernel, server/desktop
mode, and any virtualisation software. That's all.
- kptr_restrict is fixed under grsecurity (it's unwriteable)
- grsecurity patch creation is now significantly abstracted
- only need revision, version, and SHA1
- kernel version requirements are asserted for sanity
- built kernels can have the uname specify the exact grsec version
for development or bug reports. Off by default (requires
`security.grsecurity.config.verboseVersion = true;`)
- grsecurity sysctl support
- By default, disabled.
- For people who enable it, NixOS deploys a 'grsec-lock' systemd
service which runs at startup. You are expected to configure sysctl
through NixOS like you regularly would, which will occur before the
service is started. As a result, changing sysctl settings requires
a reboot.
- New default group: 'grsecurity'
- Root is a member by default
- GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID,
making it possible to easily add users to this group for /proc
access
- AppArmor is now automatically enabled where it wasn't before, despite
implying features.apparmor = true
The most trivial example of enabling grsecurity in your kernel is by
specifying:
security.grsecurity.enable = true;
security.grsecurity.testing = true; # testing 3.13 kernel
security.grsecurity.config.system = "desktop"; # or "server"
This specifies absolutely no virtualisation support. In general, you
probably at least want KVM host support, which is a little more work.
So:
security.grsecurity.enable = true;
security.grsecurity.stable = true; # enable stable 3.2 kernel
security.grsecurity.config = {
system = "server";
priority = "security";
virtualisationConfig = "host";
virtualisationSoftware = "kvm";
hardwareVirtualisation = true;
}
This module has primarily been tested on Hetzner EX40 & VQ7 servers
using NixOps.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Realistically, common-config is useful, but there are a lot of things in
there that are non-optionally specified that aren't always useful. For
example, when deploying grsecurity, I don't want the bluetooth,
wireless, or input joystick/extra filesystem stack (XFS, etc), nor the
staging drivers tree.
The problem is that if you specify this in your own kernel config in the
grsecurity module, by saying 'BT n' to turn off bluetooth,
common-config turns on 'BT_HCIUART_BCSP y', which then becomes unused
and errors out.
This is really just an arbitrary picking at the moment, but it should be
OK.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Lockdep doesn't *really* require the kernel package - just the kernel
sources. It's really a user-space tool just compiled from some portable
code within the kernel, nothing more.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
NB: This currently doesn't add a working musl-wrapper around musl-gcc to
allow it to work properly (musl has its own dynamic linker as well as
libc too which must be accounted for). But at the moment it builds fine,
and I plan on working more on it in the future. So lets get it
integrated and building on Hydra.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This reverts commit 0194a44d63 because
it breaks udisks on 13.10 (e.g. running "udisks --enumerate" will
print "Unit udisks.service failed to load").
(cherry picked from commit d7daf1a47f)
This is necessary for gradm's learning mode to work, as otherwise the
/nix/store directory is marked hidden, which causes the kernel to reject
the linker loading ld-linux.so
Signed-off-by: Austin Seipp <aseipp@pobox.com>
We alredy rewrote /sbin/gradm, which technically matches
/sbin/gradm_pam, so this ends up working exactly as we want. Otherwise
we rewrite twice and gradm can't execute the PAM module with '-p'
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- longterm: 3.4.83 -> 3.4.85
- longterm: 3.10.33 -> 3.10.35
- longterm: 3.12.14 -> 3.12.15
- stable: 3.13.7 -> 3.13.8
NOTE: This will break the testing grsec kernel at the moment (there's
not a 3.13.8 patch yet), but it's destined to be upgraded to 3.14 soon
anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- longterm: 3.4.83 -> 3.4.85
- longterm: 3.10.33 -> 3.10.35
- longterm: 3.12.14 -> 3.12.15
- stable: 3.13.7 -> 3.13.8
NOTE: This will break the testing grsec kernel at the moment (there's
not a 3.18.8 patch yet), but it's destined to be upgraded to 3.14 soon
anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Lockdep is the kernel's locking validation/debugging tool and has seen
heavy pro-active usage and development. In Linux 3.14, it's now
available directly to userspace for the same purpose. It comes with a
convenient utility to LD_PRELOAD a shared library for validation, or a
user-space API to link to directly.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Latest update to udisks in 344f2e65 broke it for me. Fix it by doing the
following:
- Add udisks.service to /etc/systemd/system (via systemd.packages)
- Fix path to udisks-daemon in udisks.service (libexec/ instead of lib/)
- Make dhcp work, use dhcpcd without udev in container
- Make login shell work, patch getty to not wait for /dev/tty0
- Make ssh work, sshd/pam do not start session
looking at our git history, I think it is very peculiar that we
managed to have this version (22.21) 2 months before release :)
So I think we were using some beta/rc that accidentally got called
22.21
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
This version just got released two days ago, while we were working for
cross-builds on 5.0.2. From the release notes it shouldn't introduce any
incompatibilities.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
GCC doesn't support attributes on enumerators, which could pose a
problem but fortunately not in this case. Here a
__attribute__((weak_import)) is used, which doesn't make much sense for
enumerators anyway (noone will die because the corresponding enumerator
won't be referenced either in older OS X versions).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
At the moment, this includes only dyldinfo, dwarfdump and dsymutil, but
we'll see whether we need more of these utilities later.
Tho reason those are wrapped in cctools-port is because it is the
binutils used to cross-compile for Mac OS X.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This provides a port of Mac OS X's CoreFoundation and is needed if we
want to be able to run dsymutil using maloader.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This toolchain contains Mach-O binaries and might not be useful in the
first place, but there are programs like dsymutil, where Apple didn't
release the source code, so we need a Mach-O loader...
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This basically is binutils for Mac OS X, but ported to work on
(GNU/)Linux and FreeBSD.
And it's up-to-date as well! I'm mentioning this, because it was quite
hard to find a recent port of it and I just accidentally stumbled on it
while trying to do the port by myself.
So thanks to @tpoechtrager for doing this.
Also, I've added two more patches, which essentially are:
* ld-rpath-nonfinal:
This allows -rpath to be used for linking non-final builds, which
was allowed for earlier versions of cctools and got a check for
that in more recent versions.
* ld-ignore-rpath-link:
Ignores the -rpath-link option, because the cross-wrapper uses it
in different places. Unfortunately, the cctools linker doesn't
support it, so we might need to implement this later if it's
possible (I'm not a Mach-O man^H^H^Hexpert).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This package provides the SDK and standard library needed for
cross-compiling to Mac US X. We're using xpwn here to extract the DMG.
Also, this version (XCode 5.0.2) only contains the SDKs for version 10.9
and 10.8, so we might need to add requireFile directives for older
versions as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
CAN userspace utilities and tools (for use with Linux SocketCAN).
There is no real "homepage" for this project (the only thing I could
find was the gitorious page) and they haven't produced any proper
releases (source archives and/or git tags), even though git history goes
back to 2006 and things seem stable.
It turns out that some of gcc 4.8's aggressive optimizations may
cause minor filesystem corruption in ZFS. To fix it, a patch was
cherry-picked from the upstream's git tree.
See: https://github.com/zfsonlinux/zfs/pull/2051
This is primarily going to be used for vmTools.runInWindowsVM, but in
theory, it could also work with Nix on CygWin which I haven't tested.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The winpthreads library is part of the same source package, so let's
just override the name and the source directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Note that currently this depends on the default nixpkgs mesa and pango.
It may be possible to build more limited versions that don't e.g. depend
on the full X stack without limiting kmscon (which of course doesn't use
X).
Depends on libtsm, added in the same commit.
Signed-off-by: Shea Levy <shea@shealevy.com>
This is a second attempt at unifying the generic and manual-config
kernel builds (see #412 for the last time).
The set of working kernel packages is a superset of those that work on
master, and as the only objection last time was the size of the $dev
closure and now both $out and $dev combined are 20M smaller than $out on
master (see message for ac2035287f), this
should be unobjectionable.
Signed-off-by: Shea Levy <shea@shealevy.com>
Based on access analysis with strace, I determined an essentially
minimal required set of files from the kernel source that was needed to
build all current kernel packages on 3.10, which ultimately resulted in
keeping 30M of source. Generalizing from that minimal set, which
required ad-hoc specifications of which headers outside of include/ and
arch/*/include and which files in the scripts/ directory should be kept,
to a policy of keeping all non-arch-specific headers that aren't part of
the drivers/ directory and the entire scripts/ directory added an
additional 17M, but there was nothing in the analysis that indicated
that that ad-hoc specification was at all complete so I think the extra
hit is worth the likely greater compatibility.
For reference, we now keep:
* All headers that are NOT in arch/${notTargetArch}/include or drivers/
* The scripts/ directory
* Makefile
* arch/${targetArch}/Makefile
IMO the most likely cause of future problems are the headers in
drivers/, but hopefully they won't actually be needed as they add 50M
Ideally kernel packages would only use include and
arch/${targetArch}/include, but alas this is observably not the case.
master:
* $out
* size: 234M
* references-closure: linux-headers, glibc, attr, acl, zlib, gcc,
coreutils, perl, bash
merge-kernel-builds:
* $out
* size: 152M
* references-closure: none
* $dev
* size: 57M
* references-closure: linux-headers, glibc, zlib, gcc
So even with the non-minimal set we still beat out master. Keeping the
drivers headers would make us only slightly bigger.
Signed-off-by: Shea Levy <shea@shealevy.com>
