You are not logged in.
Does anyone have any information about what is happening upstream with regard to the 4.16 series linux-hardened kernel? Looking at the 4.16 branch of linux-hardened on GitHub, I noticed that, yesterday, @anthrax put in pull request for a rebased patch set on top of 4.16.4. Apart from that, there has only been the initial commit of @torvalds linux-4.16-rc3 at the end of February.
I've tried a Google search and looking on the CopperheadOS website, but can’t seem to find any kind of explanation.
If anybody knows more about what is happening, I would be grateful if they could satisfy my curiosity.
Irvine
Last edited by IrvineHimself (2018-04-26 21:48:14)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
Main developer isn't interested in developing patchset for x86 architecture anymore. There is a chance for keeping rebase for new major kernel releases (4.16,4.17,4.18, etc.). You can ask on ##linux-hardened irc channel on freenode.
Offline
Thanks for the info, I hope we manage to keep the rebased linux-hardened patch set. If not, does anyone know if there is a plan B with regard to a grsec/hardened replacement, or, alternatively, if there are a comparably set of hardening patches under development which I could apply myself?
I had a look at Alpine linux on GitHub to see what they were using as a grsec replacement, but their kernel project seems dead in the water.
To explain my interest: At the moment, I have an easily implemented, (no specialist knowledge required,) security model, which uses the apparmor-enabled version of linux-hardened with the apparmor-enabled version of Firejail. If linux-hardened is dead, I could switch to the apparmor-enabled version of the vanilla kernel, but for some time I have been mulling switching to SELinux, (along with SELinux sandboxes.)
What has been putting me off this switch is that my current security model is very easy to implement, while, on the other hand, SELinux, not only has an extremely unfriendly reputation, but also, the refpolicy's compatibility with Arch Linux packages is not perfect
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
I had a look at Alpine linux on GitHub to see what they were using as a grsec replacement, but their kernel project seems dead in the water.
Alpine switched to the 4.14 LTS branch with their own hardened configuration after the Meltdown/Spectre snafu.
They also have full PIE for all their binaries (unlike Arch) and the musl libc base should reduce the attack surface so it's still a good choice.
There is an unofficial port of the last publicly available grsec patch:
https://github.com/minipli/linux-unofficial_grsec
And Debian have an old version in {stretch,jessie}-backports:
https://packages.debian.org/stretch-bac … rsec-amd64
^ The deb-src repositories will have the source code for that.
I would personally recommend OpenBSD for anything important but that's probably off-topic
Offline
@Head_on_a_Stick thanks for the info it's given me some ideas, though I should add that I have no wish to move away from Arch. I will definitely be taking a closer look musl, which I believe is in the official repos. Also, I think taking a closer look at security focused custom configurations could be a very productive idea.
The problem with old grsec patch sets is that the Linux kernel is highly dynamic and the patches can quickly become outdated and/or irrelevant, thus leading to a false sense of security.
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
I will definitely be taking a closer look musl, which I believe is in the official repos.
Unless you want to build every package against this C library, it being in the repos does not help you much...
Offline
Unless you want to build every package against this C library, it being in the repos does not help you much...
Why am I not surprised?
I love Arch, the way it manages to cater for people like me; who like to tinker and have a wide range of interests is amazing. However, sometimes catering for this wide range of interests has a definite downside.
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
They also have full PIE for all their binaries (unlike Arch) and the musl libc base should reduce the attack surface so it's still a good choice.
https://www.archlinux.org/todo/hardenin … r-removal/
It just requires rebuilding all packages that haven't been rebuilt since July... we use PIE by default now.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Just to update: The @stinger has done a rebase of @anthranx's pull request for the 4.16 branch, commenting
I did a rebase with some commits left out. I'm not planning on tagging a release for 4.16 with the current state of things though.
Even though I am not sure how this will work out in practice, since the comments seem to imply this is still very much a work in progress, I think @anthranx deserves some major kudos
Edit:
Added link to pull request
Last edited by IrvineHimself (2018-04-26 13:48:26)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
Just to let everybody know, @anthrax has cloned the rebased 4.16 branch with tagged releases for 4.16.5.a and 4.14.37.a
The updated linux-hardened binary is already in the repos, and, for those who are interested, the updated PKGBUILD for linux-hardened-apparmor will be posted to the AUR just as soon as I finish the test build and check everything is working as expected, (about an hour.)
All the best and congrats to @anthrax
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline