Tails

#1 Updated by ioerror 2014-07-24 12:17:44

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.

#3 Updated by intrigeri 2014-07-24 12:31:56

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

#4 Updated by ioerror 2014-07-24 13:19:03

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 2014-07-24 13:39:40

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

#7 Updated by intrigeri 2014-07-24 13:49:18

> 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 2014-07-24 17:26:35

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 2014-07-24 20:19:17

> 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 2014-07-24 23:03:26

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:
>
> # incrementally drop rough research material on the blueprint (wiki)
> # sum-up initial pros/cons on the blueprint, and discussion thereof
> # possibly (code) experiments to validate the aforementioned things
> # discussion on the mailing-list, if needed, based on the aforementioned organized info and test results
> # design doc on the blueprint to sum up the decision(s)
> # refine implementation
> # 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.

#12 Updated by Dr_Whax 2014-09-29 15:52:49

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 2014-09-30 10:29:48

> * 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 2014-09-30 14:29:36

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 2014-12-01 22:34:41

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 2014-12-03 15:42:20

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 2014-12-03 18:38:06

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.

#20 Updated by intrigeri 2015-01-08 12:21:24

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 2015-01-08 12:29:46

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 (Feature #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 2015-01-08 17:43:32

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 2015-01-08 22:18:03

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.

#26 Updated by intrigeri 2016-01-05 17:06:52

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 Feature #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 Feature #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.
  • see Jake’s tweaks on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#502 and follow-ups
  • https://micahflee.com/2016/01/debian-grsecurity/
  • paxctld is in Debian
  • paxrat is in Debian sid and will probably be in Stretch [updated: 2016-11-30]

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 :)

#29 Updated by cypherpunks 2016-08-25 14:24:00

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 2016-08-26 00:57:14

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 2016-08-26 12:31:36

> 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 2016-08-26 15:17:25

> 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 2016-12-31 21:05:36

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 2016-12-31 21:27:42

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.

#36 Updated by intrigeri 2017-01-01 18:27:20

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

#41 Updated by intrigeri 2017-01-02 18:01:49

> * After filling the memory with a known pattern and rebooting, the pattern can’t be found. […]

Moved to Feature #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 2017-01-03 10:38:53

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

#43 Updated by intrigeri 2017-01-03 10:44:26

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 Feature #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 2017-01-06 02:54:26

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 2017-03-04 00:53:24

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 2017-03-15 02:00:48

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 2017-03-15 07:44:00

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

Very sad :/

#48 Updated by cypherpunks 2017-03-30 03:59:33

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 2017-03-30 09:45:04

> 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 2017-04-01 03:25:03

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 2017-04-01 06:50:07

> 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 2017-04-03 01:54:13

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.

#53 Updated by intrigeri 2017-04-29 08:04:05

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

#54 Updated by cypherpunks 2017-05-13 02:47:38

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.

#57 Updated by cypherpunks 2017-10-06 12:21:45

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 2017-10-07 05:33:40

> 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 2018-06-04 05:39:33

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).