Project

General

Profile

Feature #7649

Include a grsecurity-patched kernel

Added by ioerror over 5 years ago. Updated over 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
01/07/2015
Due date:
% Done:

100%

Feature Branch:
feature/7649-grsec
Type of work:
Research
Starter:
No
Affected tool:

Description

Debian now has a grsec protected kernel.


Subtasks

Feature #8600: Evaluate a grsec kernel from spender's build service in TailsRejected

Feature #8602: Compare Debian kernel configuration with the one used in spender's grsec build serviceRejected

Feature #8604: Evaluate a grsec kernel from corsac's APT repository in TailsRejected

Feature #8605: Compare Debian kernel configuration with the one used in Corsac's grsec kernelsRejected

Feature #8606: Ask spender to apply the aufs patch in his pre-built grsec kernelsRejected

Feature #12104: Decide whether we can drop DKMS modules supportRejected

Feature #12107: Can PAX_MEMORY_SANITIZE replace memory erasure on shutdown?Resolved

Feature #12110: Evaluate grsec's performance hitRejected


Related issues

Related to Tails - Feature #10040: Publish next steps to get Grsecurity in Tails Rejected 08/14/2015 12/26/2017
Blocked by Tails - Feature #10298: Upgrade to Linux 4.x Resolved 08/11/2015

Associated revisions

Revision 81ae6446 (diff)
Added by Tails developers almost 3 years ago

Have live-boot use overlayfs as its union filesystem.

aufs doesn't play well with grsec.

Refs: #7649, #8415

Revision 09524288 (diff)
Added by intrigeri almost 3 years ago

Install a Linux kernel that includes the grsecurity patch (refs: #7649).

History

#1 Updated by ioerror over 5 years ago

I've asked the Subgraph folks to comment here so that we may share a unified kernel configuration and contribute resources towards a shared hardened kernel.

#2 Updated by intrigeri over 5 years ago

  • Category deleted (212)
  • Target version deleted (Hole in the Roof)

#3 Updated by intrigeri over 5 years ago

I'm glad to see you're making progress on this :)

#4 Updated by ioerror over 5 years ago

One possible option is to do the kernel build the Debian way:

https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage

Another possible option is to take a vanilla kernel and simply add the patches that we want/need such as grsec, as well as having a totally custom .config file.

#5 Updated by ioerror over 5 years ago

We may be interested in looking at the Mempo Debian page and how they build kernels:

https://wiki.debian.org/Mempo
https://wiki.debian.org/SameKernel#grsecurity

#6 Updated by intrigeri over 5 years ago

  • Blueprint set to https://tails.boum.org/blueprint/kernel_hardening/

#7 Updated by intrigeri over 5 years ago

We may be interested in looking at the Mempo Debian page and how they build kernels: [...]

I recommend putting such information on the corresponding blueprint ; this seems to be a better place to organize information than comments on this ticket, that quickly will get messy otherwise. Thanks in advance :)

#8 Updated by ioerror over 5 years ago

intrigeri wrote:

We may be interested in looking at the Mempo Debian page and how they build kernels: [...]

I recommend putting such information on the corresponding blueprint ; this seems to be a better place to organize information than comments on this ticket, that quickly will get messy otherwise. Thanks in advance :)

I'd like to discuss different options before we setting on a blueprint - namely - if anyone has thoughts on which way to go, we could capture that first. Does that seem reasonable? Or should we just do that on the blueprint page?

#9 Updated by intrigeri over 5 years ago

I'd like to discuss different options before we setting on a blueprint - namely - if
anyone has thoughts on which way to go, we could capture that first. Does that seem
reasonable? Or should we just do that on the blueprint page?

The way I would do it is:

  1. incrementally drop rough research material on the blueprint (wiki)
  2. sum-up initial pros/cons on the blueprint, and discussion thereof
  3. possibly (code) experiments to validate the aforementioned things
  4. discussion on the mailing-list, if needed, based on the aforementioned organized info and test results
  5. design doc on the blueprint to sum up the decision(s)
  6. refine implementation
  7. merge!

But well, really, I was just suggesting. As long as you can provide the info in some digestible way when initiating the next discussion that's needed, I'm completely happy :)

#10 Updated by ioerror over 5 years ago

intrigeri wrote:

I'd like to discuss different options before we setting on a blueprint - namely - if
anyone has thoughts on which way to go, we could capture that first. Does that seem
reasonable? Or should we just do that on the blueprint page?

The way I would do it is:

  1. incrementally drop rough research material on the blueprint (wiki)
  2. sum-up initial pros/cons on the blueprint, and discussion thereof
  3. possibly (code) experiments to validate the aforementioned things
  4. discussion on the mailing-list, if needed, based on the aforementioned organized info and test results
  5. design doc on the blueprint to sum up the decision(s)
  6. refine implementation
  7. merge!

But well, really, I was just suggesting. As long as you can provide the info in some digestible way when initiating the next discussion that's needed, I'm completely happy :)

Ok. I'm going to do some kernel builds tomorrow and whatever I end up with for building the kernel, I'll post on this bug report. Afterwards, I'll move on to testing it and when I have a full cycle decided, I'll make a blueprint to document it in a straight forward manner.

#11 Updated by intrigeri about 5 years ago

  • Status changed from New to Confirmed

What's the status on this one?

Also, see the Q&A at the end of Ben Hutchings talk about Linux kernel at DebConf14: getting a grsec kernel into the archive doesn't look that crazy, in the end, as it now seems acceptable to have it track a version of Linux that gets long-term support from the grsec team, and not to apply the Debian patches to it (hence, removing one of the major difficulties, that is to make the grsec and Debian patchset coexist peacefully without introducing security issues when resolving conflicts).

#12 Updated by Dr_Whax about 5 years ago

I have a suggestion after thinking and watching the video that intrigeri added.

On the Debian side:
  • Create a team consisting of various people who can deal with packaging, security, updates and the very much needed bureaucracy within Debian.
  • Talk with people from mempo(I did already, they seem interested), subgraphOS(No doubt they would like to help out) and maybe Corsac(I didn't talk to him yet) to help found this Debian Grsecurity team.
  • Come up with a plan to start the process of an "alternative" kernel rather than a standard kernel. This includes an update procedure and testing procedure.
  • Keep Debian Kernel/Security team in the loop and what their thoughts are.
  • Package the Deb file and upload it.
  • ...
  • Profit \o/

In all steps we should include spender and the PaX team.

Some other notes is that I will study the previous work of Mempo and Corsac, hopefully soon, we can announce the team and our plans.

I started a webpage here: https://wiki.debian.org/Teams/Grsecurity and an irc channel on OFTC: #debian-grsecurity.

#13 Updated by intrigeri about 5 years ago

  • Package the Deb file and upload it.

+ maintain this package for a full release cycle, and demonstrate the team is able to do that appropriately :)

FWIW, this plan looks good to me.

#14 Updated by Dr_Whax about 5 years ago

intrigeri wrote:

  • Package the Deb file and upload it.

+ maintain this package for a full release cycle, and demonstrate the team is able to do that appropriately :)

FWIW, this plan looks good to me.

Indeed! I have a lot more questions especially regarding how the update process would look like, since updates are mostly security updates no? Also, most probably won't get done so it can get into Jessie. But maybe as a backport? Who knows!

#15 Updated by Dr_Whax almost 5 years ago

Quick update: Spender from Grsecurity has been working on a kernel-build service and I have been beta-testing it. It doesn't seem stable yet, but I provided spender with some feedback on testing out an 3.2.64 kernel on a wheezy machine.

Hopefully, this can open a path of us getting an kernel from spender's build service for experimentation. Options so far are:

  • 3.2.x
  • 3.14.x

#16 Updated by Dr_Whax almost 5 years ago

Anonym mentioned the following on IRC, i'm documenting it here so it isn't lost.

If you plan to build a kernel and only include one x86_64 kernel it will break in particular some scripts in config/binary_local-hooks/

Make sure to use i386 and x86_64 builds, else you will have to hack your way out of it.

#17 Updated by intrigeri almost 5 years ago

I suspect syslinux is able to check whether a given file exist in our ISO filesystem (e.g. config/grsec), and if yes, then switch to a different set of config files, that display the same menu, autodetect 32 vs. 64-bit too, and boot into the grsec kernels.

Or, to start with, these alternate config files could drop the autodetection bits, and only support 64-bit.

#18 Updated by intrigeri almost 5 years ago

  • Description updated (diff)

#19 Updated by intrigeri almost 5 years ago

  • Description updated (diff)

#20 Updated by intrigeri almost 5 years ago

As reported by DrWhax on IRC after he discussed this with Patrick (Whonix), there's another open issue: PaX flags need to be defined, set, maintained and preserved over upgrades; paxctld might help.

This problem could be worse for users who install additional software, but at least to start with, we'll let those who pick the experimental grsec kernel + additional software deal with the consequences themselves.

#21 Updated by intrigeri almost 5 years ago

Apparently, all grsec kernels we could ~easily test in Tails lack support for aufs, so it may be that we have to:

  • either build our own experimental kernel from one of the existing sources (likely, Corsac's one) with the aufs patch on top;
  • or, fix the overlayfs vs. Tails situation (#8415) and then wait for a grsec patch to appear for whatever version of Linux has all the overlayfs features we want, most notably support for multiple read-only lower layers (hopefully 3.20).

#22 Updated by EmbraceCryptoAnarchyStopSocialists almost 5 years ago

Hi, in http://deb.mempo.org we will try to:
- create proper Debian-Sources package
- use new reproducible dpkg

Our solution can be used by anyone, it has following parts:

1) downloads, GPG checks grsec patches, updates config etc
2) downloads, GPG checks vanilla kernel
3) applies patch and a small extra patch to make the SEED deterministic instead random
4) generates the SEED in a way that is provably random (using a hash of recent block of bitcoin, well in this case of litecoin)

5) checks if dependencies are in correct version (compiler, libc etc)
6) sets all details needed for build to be deterministic - as described on https://wiki.debian.org/SameKernel#How_this_works (that will be no longer needed with new dpkg let's hope) - it was only way to do it when we started with the project around year ago.

7) executes the build etc

We plan to update imporove points 6, 7 to be fully standarized debian process, hopefully in next weeks even.

So far, our releases of Kernel seem to be the only ones releases in timely manner, at 1-2 day delay from grsec - we have 3 maintainers including me (rfree), kocka.

I hope we would succeed to make the solution also "debian-kosher", because it is most throughly maintained one (100 releases during > year, now at release 98 since started counting),
and that some of scripts you will find useful :)

It seems simple to just grab and apply patch and build, but in reality it took weeks of work to polish details (not to mention work spent on maintaining build+repo).

If you have any questions please join us on #mempo - we are on irc.freenode.org , oftc (tor works) and irc2p.
Repeat question each few hours and when someone is around we will reply eventually.

Btw. Thanks for your work on Tails too (as this is my first message here)

#23 Updated by Dr_Whax almost 5 years ago

I spend a few hours looking into the Debian patches. There's a bunch of patches, mostly related to specific architectures, x86, S390, etc.

Probably, we only really care about x86 and x86_64, maybe in a few years from now, you would want to have ARM* but for now, I don't think we are even considering supporting other architectures than Intel one's.

If so, I guess one might want to apply Debian's x86 patches and try to apply Grsecurity patches and see what conflicts and report those conflicts. Same goes for x86_64.

#24 Updated by intrigeri almost 4 years ago

  • Description updated (diff)

linux-grsec made it out of NEW! I'm going to update the subtasks and various ticket metadata to make it clear what's blocking us from shipping that kernel right now, and what the next steps are to resolve this problem :)

#25 Updated by intrigeri almost 4 years ago

#26 Updated by intrigeri almost 4 years ago

So, my understanding is that there are two main blockers:

  • We need either aufs or overlayfs, but:
    • Both src:linux-grsec lack aufs support. Recent src:linux 4.x has some support patches that would allow us to build aufs out-of-tree (see #10298 for details), but they conflict with the grsec patchset so were dropped in src:linux-grsec. I asked Corsac, and has no personal interest in dealing with that conflict himself, but if I got it right, he would accept patches.
    • We're not ready for overlayfs, see remaining subtasks of #8415 to see what the blockers are.
    • Note that our WIP branch for overlayfs does boot! So the lack of complete overlayfs support is a blocker for releasing Tails with grsec, but it doesn't prevent anyone from working on the other missing bits, that it:
  • To get a somewhat working system, PaX flags need to be defined, set, maintained and preserved over upgrades (paxctld and paxrat might help); and various grsec toggles and switches must be touched. I think that we should focus on making it boot into a functional Tails desktop first: it's no use dealing with the auxiliary problems before we ensure that there's no big blocker we don't know about yet.

I think the focus should be, for anyone interested, to demo a Tails branch that builds an ISO that boots with a grsec kernel into a functional desktop. I bet this will motivate others to deal with the aufs/overlayfs bits, for example :)

#27 Updated by intrigeri almost 4 years ago

  • Related to Feature #10040: Publish next steps to get Grsecurity in Tails added

#28 Updated by intrigeri over 3 years ago

  • Assignee deleted (ioerror)

#29 Updated by cypherpunks about 3 years ago

https://sources.debian.net/src/linux-grsec/4.6.3-1%2Bgrsec201607062159%2B1~bpo8%2B1/debian/patches/features/all/

According to this, the linux-grsec 4.6.x package in jessie-backports has both aufs4 and grsecurity. Does this mean that the maintainers have resolved the conflicts between the two patchsets and are making them play nice together? If so, then this is exactly what we need to get grsecurity working easily in Tails. I've already done some work on grsecurity in Tails, but using my own modifications, which use overlayfs (and thus break AppArmor). It does mean however that I've worked out the kinks already.

Does anyone know if having both the aufs4 and grsecurity patchsets in the debian/patches/features/all/ directory means that they will both be active in the linux-grsec package? I'm currently not on a system where I'll be able to test it myself.

Also, this ticket probably shouldn't be set to 100% resolved. It's not even close.

#30 Updated by Dr_Whax about 3 years ago

cypherpunks wrote:

https://sources.debian.net/src/linux-grsec/4.6.3-1%2Bgrsec201607062159%2B1~bpo8%2B1/debian/patches/features/all/

According to this, the linux-grsec 4.6.x package in jessie-backports has both aufs4 and grsecurity. Does this mean that the maintainers have resolved the conflicts between the two patchsets and are making them play nice together? If so, then this is exactly what we need to get grsecurity working easily in Tails. I've already done some work on grsecurity in Tails, but using my own modifications, which use overlayfs (and thus break AppArmor). It does mean however that I've worked out the kinks already.

Does anyone know if having both the aufs4 and grsecurity patchsets in the debian/patches/features/all/ directory means that they will both be active in the linux-grsec package? I'm currently not on a system where I'll be able to test it myself.

Also, this ticket probably shouldn't be set to 100% resolved. It's not even close.

It's not resolved since it's disabled at the moment. The Debian kernel team needs people who want to deal with making all these patches happy and apply cleanly.

#31 Updated by cypherpunks about 3 years ago

It's not resolved since it's disabled at the moment. The Debian kernel team needs people who want to deal with making all these patches happy and apply cleanly.

The aufs4 patches are disabled in the linux-grsec kernel? It's Corsac who maintains it. I would think he would be the best person to make them apply cleanly. When I asked on IRC, I was told that there is a patch that allows them to work together without any problems. Gentoo's sys-fs/aufs3 and sys-fs/aufs4 packages contain a USE flag (optional feature set per package at install time) called pax_kernel, which applies a patch named pax-4.patch. The description is "Apply patch needed for pax enabled kernels". The contents of the patch for aufs4 are at https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/aufs4/files/pax-4.patch currently. Though I haven't tested it out, it would seem like this is what is needed to let aufs4 and grsecurity/pax play nicely together on Debian, too. If it's not already included in Corsac's linux-grsec, I'm sure he'd be willing to add it.

#32 Updated by intrigeri about 3 years ago

I would think he would be the best person to make them apply cleanly.

He told me he does not want to deal with that, and I think that insisting would not be nice.

When I asked on IRC, I was told that there is a patch that allows them to work together without any problems. Gentoo's sys-fs/aufs3 and sys-fs/aufs4 packages contain a USE flag (optional feature set per package at install time) called pax_kernel, which applies a patch named pax-4.patch. The description is "Apply patch needed for pax enabled kernels".

This sounds very interesting!

The contents of the patch for aufs4 are at https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/aufs4/files/pax-4.patch currently. Though I haven't tested it out, it would seem like this is what is needed to let aufs4 and grsecurity/pax play nicely together on Debian, too.

Last time I've tried to apply the aufs compatibility patch for aufs4-standalone on top of linux-grsec, the conflict was outside of fs/aufs/; while this patch only touches stuff in fs/aufs/. Maybe I got it wrong.

#33 Updated by intrigeri almost 3 years ago

intrigeri wrote:

When I asked on IRC, I was told that there is a patch that allows them to work together without any problems. Gentoo's sys-fs/aufs3 and sys-fs/aufs4 packages contain a USE flag (optional feature set per package at install time) called pax_kernel, which applies a patch named pax-4.patch. The description is "Apply patch needed for pax enabled kernels".

This sounds very interesting!

The contents of the patch for aufs4 are at https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/aufs4/files/pax-4.patch currently. Though I haven't tested it out, it would seem like this is what is needed to let aufs4 and grsecurity/pax play nicely together on Debian, too.

I've tried it. That patch is meant to apply on top of a grsec kernel tree, that has the aufs patches applied, including the one that introduces the aufs module. But Debian's src:linux only applies the aufs4 compatibility patches, that allow building the out-of-tree aufs kernel module (that is itself packaged in aufs-dkms). So that patch doesn't work as-is for Debian... unless aufs support is reintroduced in there.

Last time I've tried to apply the aufs compatibility patch for aufs4-standalone on top of linux-grsec, the conflict was outside of fs/aufs/; while this patch only touches stuff in fs/aufs/. Maybe I got it wrong.

Confirmed (requires a testing/sid system that has the deb-src for sid):

sudo apt-get install build-essential devscripts fakeroot
sudo apt-get build-dep linux-grsec
debcheckout linux-grsec
apt-get source --download-only linux-grsec
cd linux-grsec
git checkout -b grsec/sid origin/grsec/sid
# re-enable aufs4 in debian/patches/series, commit
debian/rules orig
debian/rules debian/control
fakeroot debian/rules binary-arch_amd64_grsec_real
fakeroot debian/rules source
[...]
Applying patch features/all/grsec/grsecurity-3.1-4.8.15-201612151923+debian.patch
1 out of 9 hunks FAILED
1 out of 19 hunks FAILED
1 out of 25 hunks FAILED
1 out of 71 hunks FAILED
Patch features/all/grsec/grsecurity-3.1-4.8.15-201612151923+debian.patch does not apply (enforce with -f)
debian/rules.real:143: recipe for target 'debian/stamps/source_grsec' failed
[...]

Then, if I do

cd debian/build/source_grsec/
QUILT_PATCHES='patch/to/my/linux-grsec.git/debian/patches' \
QUILT_SERIES=series-grsec \
QUILT_PC=.pc \
quilt push --quiltrc - -a -q --fuzz=0 -f

I see:

Applying patch features/all/grsec/grsecurity-3.1-4.8.15-201612151923+debian.patch
1 out of 9 hunks FAILED -- saving rejects to file fs/xattr.c.rej
1 out of 19 hunks FAILED -- saving rejects to file include/linux/mm.h.rej
1 out of 25 hunks FAILED -- saving rejects to file kernel/fork.c.rej
1 out of 71 hunks FAILED -- saving rejects to file mm/mmap.c.rej

The conflicts are caused by:

  • aufs4-mmap.patch replaces get_file(file) with vma_get_file(tmp) in kernel/fork.c, while grsec moves the surrounding code to a new dup_vma function and calls it; dup_vma calls get_file(file); does it need to call vma_get_file instead?
  • mm/mmap.c: I think that's just line number fuzz
  • lines aufs4-mmap.patch inserts in include/linux/mm.h: fixing it should be trivial
  • this tiny change in aufs4-standalone.patch, which breaks the context of a grsec hunk; fixing it should be trivial:
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -214,6 +214,7 @@ vfs_getxattr_alloc(struct dentry *dentry, const char *name, char **xattr_value,
     *xattr_value = value;
     return error;
 }
+EXPORT_SYMBOL_GPL(vfs_getxattr_alloc);

That is 3 minor things I could take care of (and possibly maintain) myself, and one issue I personally don't feel comfortable tackling.

#34 Updated by intrigeri almost 3 years ago

intrigeri wrote:

The contents of the patch for aufs4 are at https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/aufs4/files/pax-4.patch currently. [...]

I've tried it. That patch is meant to apply on top of a grsec kernel tree, that has the aufs patches applied, including the one that introduces the aufs module. But Debian's src:linux only applies the aufs4 compatibility patches, that allow building the out-of-tree aufs kernel module (that is itself packaged in aufs-dkms). So that patch doesn't work as-is for Debian... unless aufs support is reintroduced in there.

Reintroducing aufs module source in there implies to:

- copy ./{Documentation,fs,include/uapi/linux/aufs_type.h} files to your
  kernel source tree.

(from aufs4-standalone.git:README)

I guess there used to be code to do that nicely back when src:linux included the aufs patch. But I don't know if the Linux maintainers in Debian would be ready to re-add aufs support to their plate, and I dislike the idea of maintaining our own kernel.

Another option would be to add Gentoo's patch to src:aufs-dkms... but it calls grsec-specific functions.

Next step: look at how Gento manages to add the aufs4 patch on top of their hardened kernel.

#35 Updated by intrigeri almost 3 years ago

#36 Updated by intrigeri almost 3 years ago

I gave up on the aufs+grsec thing, and had good results with overlayfs (see #9045) so I think we should focus on that for now.

#37 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #8415: Migrate from aufs to overlayfs)

#38 Updated by intrigeri almost 3 years ago

#39 Updated by intrigeri almost 3 years ago

  • Subject changed from Create experimental option for grsec kernel to Include a grsecurity-patched kernel
  • Description updated (diff)

#40 Updated by intrigeri almost 3 years ago

  • Status changed from Confirmed to In Progress
  • Feature Branch set to feature/7649-grsec

Here are the remaining issues I could spot by running the (non-fragile part of the) test suite; note that this is in addition to the issues reported on #9045#note-13, since this branch is based on feature/8415-overlayfs-stretch:

  • After filling the memory with a known pattern and rebooting, the pattern can't be found. That's probably because grsec sanitizes all freed memory by default. There's no runtime control over this feature, so I don't know how we can repair this test case. Except... maybe this grsec feature allows us to entirely drop our own erase memory on shutdown feature? GRKERNSEC_KMEM (enabled in the Debian grsec kernel) disables kexec support anyway, so our current implementation can't possibly work with grsec.
  • OpenPGP Applet doesn't fully start, some operations are blocked by grsec.
  • Ejecting the USB boot device doesn't trigger shutdown, while it works fine when started from DVD.
  • SSH, GnuPG CLI and re-running htpdate fail: can't reproduce by hand, possible temporary network problem; will retry.

And once everything works fine, we should tell grsec to stop logging everything:

kernel.grsecurity.audit_chdir = 0
kernel.grsecurity.audit_mount = 0
kernel.grsecurity.audit_ptrace = 0
kernel.grsecurity.chroot_execlog = 0
kernel.grsecurity.exec_logging = 0
kernel.grsecurity.forkfail_logging = 0
kernel.grsecurity.resource_logging = 0
kernel.grsecurity.rwxmap_logging = 0
kernel.grsecurity.signal_logging = 0
kernel.grsecurity.timechange_logging = 0

And maybe lock grsec runtime configuration:

kernel.grsecurity.grsec_lock = 1

#41 Updated by intrigeri almost 3 years ago

  • After filling the memory with a known pattern and rebooting, the pattern can't be found. [...]

Moved to #12107.

  • OpenPGP Applet doesn't fully start, some operations are blocked by grsec.

Workarounded.

  • Ejecting the USB boot device doesn't trigger shutdown, while it works fine when started from DVD.
  • SSH,

That's a local test suite config problem, doesn't happen on Jenkins.

GnuPG CLI

Apparently fixed.

and re-running htpdate fail: can't reproduce by hand, possible temporary network problem; will retry.

I see it only from time to time locally.

And once everything works fine, we should tell grsec to stop logging everything:

Done.

And maybe lock grsec runtime configuration:

Done.

#42 Updated by intrigeri almost 3 years ago

Something we'll need to evaluate is the performance hit, that seems pretty big => #12110.

#43 Updated by intrigeri almost 3 years ago

Current status: all remaining issues I'm aware of are tracked as subtasks or blocking tasks of this ticket. I have no serious plans to come back to it any time soon outside of "doing something funny to procrastinate and call it holiday", so if anyone who wants to move this forward faster: your help is warmly welcome. I would recommend focussing on #8415 first since it's a blocker, and can be merged before all grsec things are ready; but help on the subtasks of this very ticket is welcome too!

#44 Updated by cypherpunks almost 3 years ago

intrigeri wrote:

And once everything works fine, we should tell grsec to stop logging everything:

You might want to enable some non-intrusive but useful forms of logging like RWX map logging and signal logging. RWX map logging catches violations of the PAX_MPROTECT feature, and signal logging catches certain important signals. Both of these can be indicative of exploitation attempts.

Fork fail logging could also be useful since it's never triggered under normal circumstances, reports no confidential information, and can catch fork bomb attempts or RLIMIT_NPROC violations (both of which can indicate an attempt to cripple the memory wiping functionality by locking up the system).

Time change logging would also be useful because there's only one process which should ever be changing the time. If anything else attempts to change the time, it should be recorded. This feature doesn't record the timezone or clock skew, only the process which changed the system time.

#45 Updated by cypherpunks over 2 years ago

Grsecurity would have protected Tails from CVE-2017-6074 (which existed since 2006) due to both MODHARDEN and RAP, at a minimum. The current public PoCs would also have been completely mitigated in half a dozen other ways as well. Just more of a reason why this should be a higher priority than it currently is.

#46 Updated by cypherpunks over 2 years ago

Unfortunately, grsecurity is going fully private in the near future. According to spender, 4.9 will likely be the last patch released to the public. This includes both the testing and stable patches. See the discussion in #grsecurity on OFTC when spender is online. This is horrible because it affects Hardened Gentoo, SGOS, Alpine Linux, Tor Ramdisk, Copperhead OS, and more.

Since the primary reason I've been contributing to Tails recently has been to move the plan to include grsecurity forward, I don't think there's any compelling reason for me to continue with my contributions, since I see Tails as unable to be sufficiently secured for the needs of my family and friends otherwise. Unless the current situation changes, or if spender allows exemptions for distros like this (which I think will be unlikely), I'll have to reluctantly back off.

#47 Updated by intrigeri over 2 years ago

Unfortunately, grsecurity is going fully private in the near future.

Very sad :/

#48 Updated by cypherpunks over 2 years ago

On the up-side, spender has mentioned that he's "toying with the idea" of releasing a single testing patch every 2 years for the LTS kernel of the time. This would allow the community to maintain the testing patch for that kernel until the LTS expires in 2 years. If he goes through with it, then Corsac or someone else will likely continue to maintain a grsec kernel.

Unfortunately, disabling the size overflow plugin would probably be necessary to improve reliability, since known bugs that are already fixed in the commercial patches would not be fixed in the community patches, and the LTO plugin used to generate the CrapWow hash tables is private. Any fixes involving size overflows would have to be done manually and could not involve changing the hash tables. It would be possible, but it'd be a pain, possibly involving just disabling instrumentation on the problematic functions.

The same goes for RAP, where problematic functions cannot be easily found due to lacking the private RAP static analysis tools. Additionally, there are regression tests which, while simple, involve private regex searches to ensure that certain mitigations are still functioning. I don't know if there would be an issue with regressions caused during the maintenance of grsecurity for an LTS kernel, but it's something to keep in mind. Note that we would not maintain it ourselves, either way.

Well, at least there's a chance... We may have to wait for or after the announcement to see if he'll do that.

Update from IRC while I was in the middle of writing this:

<shaou_>  will the announcement mention whether or not you'll be releasing a
          sample test patch every 2 years for the community to maintain themselves?
<shaou_>  currently discussing the possibility of that with Tails devs.
<spender> i don't know that we'll commit to it in the announcement
<spender> it would turn it into an obligation instead of a gift
<spender> if we see that it's something people want, we'll do it
<spender> otherwise people will eat whatever dog food KSPP comes up with
<spender> i'll keep updating em until the announcement, maybe a little after
          that (pipacs doesn't want me to)
<spender> and it'll get handed over to "the community" 
<shaou_>  i'm sure people will want it. alpine and hardened gentoo are hopeful,
          and i'm sure tails will be, too

This means that spender will keep updating the 4.9 test patches for a short time until the announcement and possibly a little after, after which he'll give them over to the community. They will be obsolete when the 4.9 LTS is EOLed. If there's interest, he may give out a snapshot release for the next LTS, and let the community maintain it until that LTS is EOL, etc.

#49 Updated by intrigeri over 2 years ago

Well, at least there's a chance... We may have to wait for or after the announcement to see if he'll do that.

Thanks for this update!

They will be obsolete when the 4.9 LTS is EOLed.

That's concerning: we generally can't stick to the LTS kernel, as supporting newer hardware often requires a newer kernel.

#50 Updated by cypherpunks over 2 years ago

intrigeri wrote:

That's concerning: we generally can't stick to the LTS kernel, as supporting newer hardware often requires a newer kernel.

And a boot option for grsecurity would not work?

Do you believe that, in 2 years (less than two years, as 4.9 has been out for a bit), there will be much hardware out which will not be supported by the 4.9 kernel? Usually the drivers in a kernel tend to support a class of hardware devices, rather than a single, specific model. The ath9k driver should be able to support even new, unknown Atheros devices for a while.

#51 Updated by intrigeri over 2 years ago

Do you believe that, in 2 years (less than two years, as 4.9 has been out for a bit), there will be much hardware out which will not be supported by the 4.9 kernel?

Yes, absolutely, particularly in the drm area which has historically been a pain point for Tails users (and for the Tails Foundations Team), because supporting recent hardware often requires updating the kernel and/or Mesa and/or some X.Org components.

#52 Updated by cypherpunks over 2 years ago

intrigeri wrote:

Do you believe that, in 2 years (less than two years, as 4.9 has been out for a bit), there will be much hardware out which will not be supported by the 4.9 kernel?

Yes, absolutely, particularly in the drm area which has historically been a pain point for Tails users (and for the Tails Foundations Team), because supporting recent hardware often requires updating the kernel and/or Mesa and/or some X.Org components.

It's not possible to fall back to older DRM functionality in xorg.conf? I believe I've had such problems in the past for unrelated reasons, and falling back to older DRM functionality tended to work. I hope this will not be a blocker, because there is still the possibility of a fallback kernel (which could be detected and automatically selected by the bootloader, most likely), and even running Xorg against the framebuffer instead of the DRM nodes, if necessary.

#54 Updated by cypherpunks over 2 years ago

intrigeri wrote:

http://www.corsac.net/?rub=blog&post=1587

Yeah it's very unfortunate. A guy called minipli is going to maintain the 4.9 series until the LTS is EOL (though he has no plans to maintain a 4.10 or anything after that), after which other maintained forks will likely go on and be ported forward. Specifically, Alpine Linux and Subgraph OS have efforts to maintain their own kernels. There's another project called hardened-linux set up by strcat which both attempts to (very slowly) upstream features, as well as maintain a fork downstream, at least from what I gather.

So there could be reduced hardware support, depending on how good the maintainers are at promptly porting it forward, but it would be perfect for an experimental option, and it's better than nothing. Overall, I think we'll just have to wait and see how the forks work out, to see if they're viable for use in Tails. Not all hope is lost.

Spender had a bit of a shit-fit and closed off #grsecurity on OFTC, so now the primary channel is #pax on the same server, and possibly the growing ##linux-hardened on Freenode for discussion.

#55 Updated by intrigeri over 2 years ago

  • Blocked by deleted (Feature #8415: Migrate from aufs to overlayfs)

#56 Updated by intrigeri over 2 years ago

  • Status changed from In Progress to Rejected

grsec is not FOSS anymore.

#57 Updated by cypherpunks about 2 years ago

intrigeri wrote:

grsec is not FOSS anymore.

This is incorrect and a common myth. Grsecurity is still licensed under the GPL, as it is derived from the Linux kernel. The GPL does not prohibit commercialization, as long as the source code is distributed alongside the binary. In fact, the OSI definition of Open Source requires that a license not restrict sale. Closing this because of a misconception regarding licensing is not a good idea. It should remain open, to allow for other possibilities for its inclusion.

Free as in gratis != free as in libre.

#58 Updated by intrigeri about 2 years ago

intrigeri wrote:

grsec is not FOSS anymore.

This is incorrect and a common myth. Grsecurity is still licensed under the GPL,

Right.

Now, is there any legal way Tails could build a kernel with the latest grsec patchset applied and distribute the corresponding source code?

#59 Updated by cypherpunks over 1 year ago

intrigeri wrote:

intrigeri wrote:

grsec is not FOSS anymore.

This is incorrect and a common myth. Grsecurity is still licensed under the GPL,

Right.

Now, is there any legal way Tails could build a kernel with the latest grsec patchset applied and distribute the corresponding source code?

Yes as is your legal right under the GPL. Although to not have the contract terminated (which is OSS's legal right), you would have to pay a fair bit more. I don't have any price quote on-hand. I doubt Tails would ever want to pay for it though given that it's "not upstream". I think keeping this ticket closed (at least for now) is fine for that reason, but not because it's not FOSS (it is).

Also available in: Atom PDF