Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Fri, May 12, 2017, at 16:38, Alex Efros wrote: > Hi! > > On Fri, May 12, 2017 at 09:10:43PM +0200, "Tóth Attila" wrote: > > Please take a look at on the reply of PaxTeam postend on the openwall > > mailing list: > > http://openwall.com/lists/kernel-hardening/2017/05/11/2 > > What's for? It's pointless. Only very few people are really interested > (i.e. not just curious) in knowing who is paid by which company for doing > what, who makes more real bugs, and who lies about something. > > The important questions about how to keep current level of protection for > individual/small business users and how users of some distributions like > Gentoo/Ubuntu/Android can be protected with GrSec/PaX are still > unanswered. > > While large companies may buy subscription for GrSec/PaX the mentioned > above categories of users can't (correct me if I'm wrong, please) - so > effectively the change in GrSec policy makes harm and punish mostly these > categories of users. If that's real GrSec/PaX goal - it's very sad but > they probably have rights to do this (except their public reasoning > doesn't match what they actually do, so probably there are some unsaid > reasoning exists too), but if it's not their real goal - then they > probably should provide some options for these categories of users too. > > -- > WBR, Alex. Individuals can certainly request a quote -- I did -- their director of sales is very patient, considerate and accommodating. Unfortunately the price is quite a bit more than I can personally afford at present. I don't personally doubt PaXteam/Spenders stated reasoning. It appears they've encountered a quite aggravating situation with what may amount to plagiarists. The post Dr. Toth linked closely mirrored what I initially anticipated from observing kspp and the like from afar. I think they're in a crap situation and what they've done is one of the better of several bad options. So, I am considering the costs of alternative control environments for my personal systems, perhaps it will be worth the quoted price after all once I've assessed options. But, point being, if paying is not out of the question I think you should request a quote. -- 0x7D964D3361142ACF
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017.Május 8.(H) 23:12 időpontban Andrew Savchenko ezt írta: > Most likely KSPP project will come up, they are doing a good job: > bringing security features upstream fixing bugs in PaX code during > the process [1]. This is what PaX should have done long time ago, > they were even offered CII grant for this job, but refused [2]. > > [1] http://openwall.com/lists/kernel-hardening/2017/05/02/4 > [2] > https://lists.coreinfrastructure.org/pipermail/cii-discuss/2015-August/03.html Just as a follow-up regarding the argument between KSPP and Grsecurity. Please take a look at on the reply of PaxTeam postend on the openwall mailing list: http://openwall.com/lists/kernel-hardening/2017/05/11/2 Pá: Attila -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On 170508-22:49+0200, Miroslav Rovis wrote: > ... > I'll be back with an ebuild to discuss. > ... > On 170508-22:07+0200, Mathias Krause wrote: > > On 8 May 2017 at 20:08, Miroslav Roviswrote: ... > > > Unofficial forward ports of the last publicly available grsecurity patch > > > https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec > > > > > > which I cloned into my machine. ... > > ...as it used to be the case for the official grsec patch. So nothing > > has changed here. ;) But I can understand your concerns. If you're > > used to getting a patch and have to use a git repo now, it's not > > intuitive on *how* to make use of it. But, again, see below... ... > > I'm not familiar with the gentoo ebuild based package system but I > > guess patches integrate more smoothly than git repositories do. So > > here's how you generate a patch for the unofficial port for v4.9.27 > > (just pushed ;): > > > > $ git remote update I'm used to doing: $ git pull (and I think it did the same, but I need to do it all over, more below, and in my next try I'll to 'git remote update') > > [update log foo] > > $ git diff v4.9.27..v4.9.27-unofficial_grsec > > > ~/unofficial_grsec-v4.9.27.diff Yes, that is how I got the grsec patch. I named it: 4420_grsecurity-3.1-4.9.27-201705082100.patch This is what I did by comparison. The 4.9.24/ is gotten by: tar xf /usr/portage/distfiles/hardened-patches-4.9.24-1.extras.tar.bz2 and so I created: mkdir 4.9.27/, placed the content of the old 4.9.24/, except not the old patch, but the new I placed in it. See: # ls -ABRgo 4.9.24/ 4.9.24/: total 9380 -rw-r--r-- 12003 2017-04-22 17:58 _README -rw-r--r-- 1 101631 2017-04-22 17:58 1023_linux-4.9.24.patch -rw-r--r-- 1 9451813 2017-04-22 17:38 4420_grsecurity-3.1-4.9.24-201704220732.patch -rw-r--r-- 1 665 2016-11-10 01:55 4425_grsec_remove_EI_PAX.patch -rw-r--r-- 11359 2017-01-01 18:15 4426_default_XATTR_PAX_FLAGS.patch -rw-r--r-- 11444 2017-02-15 14:14 4427_force_XATTR_PAX_tmpfs.patch -rw-r--r-- 1 303 2015-08-14 08:04 4430_grsec-remove-localversion-grsec.patch -rw-r--r-- 11528 2016-08-14 12:16 4435_grsec-mute-warnings.patch -rw-r--r-- 1 641 2015-08-14 08:04 4440_grsec-remove-protected-paths.patch -rw-r--r-- 14184 2016-12-14 13:33 4450_grsec-kconfig-default-gids.patch -rw-r--r-- 12616 2016-12-14 13:32 4465_selinux-avc_audit-log-curr_ip.patch -rw-r--r-- 12553 2017-02-15 14:14 4470_disable-compat_vdso.patch -rw-r--r-- 11467 2017-01-16 22:22 4475_emutramp_default_on.patch # # ls -ABRgo 4.9.27/ 4.9.27/: total 9184 -rw-r--r-- 12003 2017-04-22 17:58 _README -rw-r--r-- 1 9352316 2017-05-08 23:47 4420_grsecurity-3.1-4.9.27-201705082100.patch -rw-r--r-- 1 665 2016-11-10 01:55 4425_grsec_remove_EI_PAX.patch -rw-r--r-- 11359 2017-01-01 18:15 4426_default_XATTR_PAX_FLAGS.patch -rw-r--r-- 11444 2017-02-15 14:14 4427_force_XATTR_PAX_tmpfs.patch -rw-r--r-- 1 303 2015-08-14 08:04 4430_grsec-remove-localversion-grsec.patch -rw-r--r-- 11528 2016-08-14 12:16 4435_grsec-mute-warnings.patch -rw-r--r-- 1 641 2015-08-14 08:04 4440_grsec-remove-protected-paths.patch -rw-r--r-- 14184 2016-12-14 13:33 4450_grsec-kconfig-default-gids.patch -rw-r--r-- 12616 2016-12-14 13:32 4465_selinux-avc_audit-log-curr_ip.patch -rw-r--r-- 12553 2017-02-15 14:14 4470_disable-compat_vdso.patch -rw-r--r-- 11467 2017-01-16 22:22 4475_emutramp_default_on.patch # And then I issued: tar cjf /usr/portage/distfiles/hardened-patches-4.9.27-1.extras.tar.bz2 4.9.27/ Similarly, looking up what tar xf /usr/portage/distfiles/genpatches-4.9-24.base.tar.xz decompresses into, actually it needs a folder created before it does so: tar xf /usr/portage/distfiles/genpatches-4.9-24.base.tar.xz -C linux , I copied it to [[ STOP, I found why the below, exactly because I didn't descend in that directory when I created, be see further below ]] However (and also logs are to follow), the patching didn't go right: # find /usr/src/linux/ -name '*.rej' /usr/src/linux/arch/x86/mm/init.c.rej /usr/src/linux/arch/x86/entry/entry_32.S.rej /usr/src/linux/mm/nommu.c.rej /usr/src/linux/mm/memory.c.rej /usr/src/linux/net/core/neighbour.c.rej /usr/src/linux/net/packet/af_packet.c.rej /usr/src/linux/net/unix/af_unix.c.rej /usr/src/linux/net/mpls/af_mpls.c.rej /usr/src/linux/include/linux/sched.h.rej /usr/src/linux/include/linux/capability.h.rej /usr/src/linux/include/linux/mm.h.rej /usr/src/linux/fs/namespace.c.rej /usr/src/linux/fs/exec.c.rej /usr/src/linux/fs/splice.c.rej /usr/src/linux/drivers/char/mem.c.rej /usr/src/linux/drivers/hv/hv.c.rej /usr/src/linux/kernel/ptrace.c.rej /usr/src/linux/kernel/cpu.c.rej # So the above happened, but (and this is the "further belows") it happened because, here's the paste: # tar tf /usr/portage/distfiles/genpatches-4.9-27.base.tar.xz | head linux/ linux/1012_linux-4.9.13.patch linux/1022_linux-4.9.23.patch
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Mon, 1 May 2017 13:58:08 + Sven Vermeulen wrote: > On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote: > > > The obvious step is indeed to stop further *current* development on > > > hardened-sources. > > > > Why not support hardened-sources while corresponding vanilla > > kernels are still supported? E.g. 4.9 is a longterm branch, so we > > should be able to keep hardened-sources-4.9* up-to-date with > > vanilla bugfixes. This will give a nice transition period for > > hardened users. > > Transition to what exactly? It doesn't really matter. Something will come up, but we need to provide users smooth experience before then. Supporting 4.9 looks like a good solution here. Most likely KSPP project will come up, they are doing a good job: bringing security features upstream fixing bugs in PaX code during the process [1]. This is what PaX should have done long time ago, they were even offered CII grant for this job, but refused [2]. [1] http://openwall.com/lists/kernel-hardening/2017/05/02/4 [2] https://lists.coreinfrastructure.org/pipermail/cii-discuss/2015-August/03.html Best regards, Andrew Savchenko pgpwmYA_JB_Yp.pgp Description: PGP signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
(thanks also to Luis Ressel for clarifications in the other email) (I'm only top posting because this reply of mine has no particularities to place it btwn any lines further below. Otherwise, I don't top post.) Mathias, I only wish to thank you for the quick reply and the tips below. And all my hopes are in you and your team/your contributors (I'm sure there will be great libre people congregating on linux-unofficial_grsec these days and weeks ahead, and longer). Make it as libre as possible! Keep fixing the kernel that Mr Linux wouldn't make secure... Yes, he and his comrades from big business caused this rift. I don't blame spender and PaX Team either And about ebuild making, I'll try my best and if I don't break apart in unsuccessful trying, I'll be back with an ebuild to discuss. Or if anybody from Gentoo hardened cares, they can teach us how to do the Gentoo details. (no more new text, only my signature in bottom) On 170508-22:07+0200, Mathias Krause wrote: > On 8 May 2017 at 20:08, Miroslav Roviswrote: > > [...] > > But I saw the other link that gives me some hope: > > > > Unofficial forward ports of the last publicly available grsecurity patch > > https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec > > > > which I cloned into my machine. (And I have just spent hours trying to > > fix an ebuild in my custom overlay and install it in my machine, to no > > avail so far, and I'm at the end of my forbearance... A little more below.) > > > > And I wonder: > > > > 1) Are there any guides for non-programmers how to install the: > > > > Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec > > https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified > > See below. > > > [...] > > > > 2) How can I check the integrity? I can: > > You figured that one already ;) > > > [...] > > The README.md is plain readme from the kernel, no mention of grsec at > > all... > > ...as it used to be the case for the official grsec patch. So nothing > has changed here. ;) But I can understand your concerns. If you're > used to getting a patch and have to use a git repo now, it's not > intuitive on *how* to make use of it. But, again, see below... > > > > > Where do I get some tips how to install? I do have the git sources, they > > verify fine... I will, hopefully, keep strong and keep trying, but I'm > > not so very sure I am able to craft an ebuild that would work and that > > would install with the local git linux-unofficial_grsec repo... > > I'm not familiar with the gentoo ebuild based package system but I > guess patches integrate more smoothly than git repositories do. So > here's how you generate a patch for the unofficial port for v4.9.27 > (just pushed ;): > > $ git remote update > [update log foo] > $ git diff v4.9.27..v4.9.27-unofficial_grsec > > ~/unofficial_grsec-v4.9.27.diff > > If you don't want to clone the git repo you can fetch the patch > directly via the github web interface: > > $ curl > https://github.com/minipli/linux-unofficial_grsec/compare/v4.9.27...v4.9.27-unofficial_grsec.diff > > ~/unofficial_grsec-v4.9.27.diff > > The pattern should be intuitive: just change "v4.9.27" for the kernel > version you want to get a patch for (v4.9.25 to v4.9.27 so far). > > The generated patch can be applied on a vanilla Linux v4.9.27 as usual > to generate the unofficial grsec kernel. > > I hope this helps! > > Cheers, > Mathias Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On 8 May 2017 at 20:08, Miroslav Roviswrote: > [...] > But I saw the other link that gives me some hope: > > Unofficial forward ports of the last publicly available grsecurity patch > https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec > > which I cloned into my machine. (And I have just spent hours trying to > fix an ebuild in my custom overlay and install it in my machine, to no > avail so far, and I'm at the end of my forbearance... A little more below.) > > And I wonder: > > 1) Are there any guides for non-programmers how to install the: > > Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec > https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified See below. > [...] > > 2) How can I check the integrity? I can: You figured that one already ;) > [...] > The README.md is plain readme from the kernel, no mention of grsec at > all... ...as it used to be the case for the official grsec patch. So nothing has changed here. ;) But I can understand your concerns. If you're used to getting a patch and have to use a git repo now, it's not intuitive on *how* to make use of it. But, again, see below... > > Where do I get some tips how to install? I do have the git sources, they > verify fine... I will, hopefully, keep strong and keep trying, but I'm > not so very sure I am able to craft an ebuild that would work and that > would install with the local git linux-unofficial_grsec repo... I'm not familiar with the gentoo ebuild based package system but I guess patches integrate more smoothly than git repositories do. So here's how you generate a patch for the unofficial port for v4.9.27 (just pushed ;): $ git remote update [update log foo] $ git diff v4.9.27..v4.9.27-unofficial_grsec > ~/unofficial_grsec-v4.9.27.diff If you don't want to clone the git repo you can fetch the patch directly via the github web interface: $ curl https://github.com/minipli/linux-unofficial_grsec/compare/v4.9.27...v4.9.27-unofficial_grsec.diff > ~/unofficial_grsec-v4.9.27.diff The pattern should be intuitive: just change "v4.9.27" for the kernel version you want to get a patch for (v4.9.25 to v4.9.27 so far). The generated patch can be applied on a vanilla Linux v4.9.27 as usual to generate the unofficial grsec kernel. I hope this helps! Cheers, Mathias
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
Hi, I don't have much to add, but I'd like to clear two misunderstandings here: On Mon, 8 May 2017 20:08:07 +0200 Miroslav Roviswrote: > And really since late in 2016 no more entries in the Changelog. Pls. > note that I'm only stating the facts, not complaining. AFAIK the Changelogs aren't updated anymore (in the whole gentoo tree). > > * NSA SELinux instead PAX MPROTECT? > I hope this is a joke. It looks like one, at first sight, but there > are half a dozen "NSA SELinux" instances to be found in the latest > hardened-sources. > > # grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig > bool "NSA SELinux Support" > ... > # > (where linux is a hardened-sources installation) > > If hardened would be down to SELinux, I wouldn't be hardening any > more. SELinux isn't a patch applied by hardened-sources, it's a subsystem of the mainline kernel. grsec was really the only significant difference between hardened-sources and gentoo-sources. Regards, Luis pgpY_BOer2s_t.pgp Description: OpenPGP digital signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On 170502-10:28+0200, Daniel Cegiełka wrote: > https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project > > It closes the topic of our discussion. > And I read all the discussion in gentoo-hardened in regard. First, I'm a user[1], and I'm trying to continue to keep safe and secure as I used to be with grsec/PaX. I figured out only yesterday about this almost two weeks old news, and I guess the then 10+ days old (slightly) unmaintained kernel 4.9.24-hardened (and there won't be any updates, correct?), may have contributed to my woes[2]: # ls -ABRgo /usr/portage/sys-kernel/hardened-sources/ ... -rw-r--r-- 1 47449 2016-12-17 02:21 ChangeLog ... -rw-r--r-- 1 1316 2017-04-22 18:18 hardened-sources-4.9.24.ebuild ... # And really since late in 2016 no more entries in the Changelog. Pls. note that I'm only stating the facts, not complaining. I really wish I learn myself and be able to contribute; acually I have occasinally contributed, marginally, to the hardened project, with testing. > worth reading: > > http://openwall.com/lists/kernel-hardening/2017/05/01/5 > > http://openwall.com/lists/kernel-hardening/2017/05/02/4 And these should not be missed: It looks like there will be no more public versions of PaX and Grsec http://openwall.com/lists/kernel-hardening/2017/05/04/20 ( Shawn's collection of links there are an eye-opener, esp. this one link which, to me, feels like sacrilege: https://mjg59.dreamwidth.org/39546.html about Karen Sandler, the executive director of the Software Freedom Conservancy, by sly means prevented to stand for LF board ) and: < same subject > http://openwall.com/lists/kernel-hardening/2017/05/02/14 ( where find what "is... unappealing." ) > this means: > > * KSPP means that keeping PaX for >4.9 will be difficult and painful, > as I pointed out previously > * NSA SELinux instead PAX MPROTECT? I hope this is a joke. It looks like one, at first sight, but there are half a dozen "NSA SELinux" instances to be found in the latest hardened-sources. # grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig bool "NSA SELinux Support" ... # (where linux is a hardened-sources installation) If hardened would be down to SELinux, I wouldn't be hardening any more. > alternatives: RSBAC > ... But I saw the other link that gives me some hope: Unofficial forward ports of the last publicly available grsecurity patch https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec which I cloned into my machine. (And I have just spent hours trying to fix an ebuild in my custom overlay and install it in my machine, to no avail so far, and I'm at the end of my forbearance... A little more below.) And I wonder: 1) Are there any guides for non-programmers how to install the: Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified UPDATE (at proofreading time: Matheus, thanks! You just PGP-signed the new tag [3], reader, skip 16 lines ) 2) How can I check the integrity? I can: $ git tag --verify v4.9.26 object d071951e08ee23cd725c2336d7ab4582bb93b0af type commit tag v4.9.26 tagger Greg Kroah-Hartman1493825816 -0700 ... $ but I can not verify Mathias Krause's commit. Pls. minipli, can you start PGP-signing... [cut more text, because you have :) ] (Continue reading, isues left here, this is the "little more below" I mentioned above.) The README.md is plain readme from the kernel, no mention of grsec at all... Where do I get some tips how to install? I do have the git sources, they verify fine... I will, hopefully, keep strong and keep trying, but I'm not so very sure I am able to craft an ebuild that would work and that would install with the local git linux-unofficial_grsec repo... I suspect the [2] below was because my kernel wasn't updated... and I do feel a little insecure at this time... --- [1] but I can understand the issues the developers have. I have some understanding of programming, and the politics with and around FOSS is easy to understand, given time and info. [2] Strange script planted with Bash https://www.croatiafidelis.hr/foss/cap/cap-170504-strange-bash/ and: Inconsistent behavior in my Gentoo OS instance https://lists.gt.net/gentoo/user/325985#325985 [3] $ git tag --verify v4.9.26-unofficial_grsec object bb9fb983874810ca4167430508e06975af700824 type commit tag v4.9.26-unofficial_grsec tagger Mathias Krause 1494181910 +0200 This is the unofficial forward port of grsecurity-3.1-4.9.24-201704252333.patch to v4.9.26 gpg: Signature made Sun 07 May 2017 20:32:02 CEST gpg:using RSA key 758532435BA4 gpg: Good signature from "Mathias Krause " [unknown] ... Primary key fingerprint: 7629 8B5B B60E DAD2 1B36 2E66 7585 3999 9243 5BA4
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
Hi! On Tue, May 02, 2017 at 09:58:18PM +0200, Daniel Cegiełka wrote: > This means that any future solution will not be compatible with current > PaX support. It doesn't means that. That may happens, or not - if someone will bother about compatibility, for example. I also think it makes sense to keep paxmarking in ebuilds, for now. If not for technical reasons, then just to avoid adding more damage. GrSec/PaX is not going anywhere, at least not immediately, there are a lot of systems which still use hardened-sources and may continue using current versions for long enough time - and they'll need that paxmarking for current and new versions of ebuilds. Plus there is a non-zero chance next solution will replace GrSec/PaX in more or less compatible way. And thus until it became clear next solution doesn't require similar paxmarking at same places or supporting paxmarking in existing ebuilds will require any noticeable effort - there is no good reason to destroy something what just works now. > Again: years of work and PaX support ends in the trash. Yeah, we already know you feel it this way. Any reason to repeat this again and again? How this will improve anything? -- WBR, Alex.
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-02 19:23 GMT+02:00 "Tóth Attila": > 2017.Május 2.(K) 18:59 időpontban Daniel Cegiełka ezt írta: >>> pax.?mark actually, since the eclass helper is called pax-mark. :) >>> I'd hold off on removing those for at least a few months, though. >>> >> >> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be >> 'paxmarked' again. Years of work and PaX support ends in the trash. > > I must aggree here. If there will be an alternative implementation marking > may regain its meaning. The same binaries need to be marked in some way or > another. I wouldn't simply dump it unless it would disturb some > functionality. Even if PAX_MPROTECT somehow comes back to the kernel, there is no guarantee that it will be compatible with current PaX ELF header (elf_phdata->p_flags & PF_MPROTECT) or PAX_XATTR_FLAGS (PAX_MPROTECT==0x0400). Next, the PaX functionality are added to the kernel gradually: one functionality per patch (eg. PAX_USERCOPY -> HARDEN_USERCOPY). This means that any future solution will not be compatible with current PaX support. Again: years of work and PaX support ends in the trash.
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-02 18:02 GMT+02:00 Luis Ressel: > On Tue, 2 May 2017 17:56:22 +0200 > Daniel Cegiełka wrote: > >> grep -r -e paxmark -e pax_kernel /usr/portage/ > > pax.?mark actually, since the eclass helper is called pax-mark. :) > I'd hold off on removing those for at least a few months, though. > If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be 'paxmarked' again. Years of work and PaX support ends in the trash. Now we see that there is a new level of security: user trust.
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Tue, 2 May 2017 17:56:22 +0200 Daniel Cegiełkawrote: > grep -r -e paxmark -e pax_kernel /usr/portage/ pax.?mark actually, since the eclass helper is called pax-mark. :) I'd hold off on removing those for at least a few months, though. Regards, Luis pgpmepOaL7otT.pgp Description: OpenPGP digital signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-02 17:28 GMT+02:00 Luis Ressel: > On Mon, 1 May 2017 09:38:43 + > Sven Vermeulen wrote: > >> The obvious step is indeed to stop further *current* development on >> hardened-sources. I don't know how many additional patchsets are being >> implemented in it (blueness? Zorry?) so I don't know if it means that >> hardened-sources in total is done with or not. > > All patches in our current patchset > (hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of > them don't even touch the kernel code, but only the Kconfig's. So > unless we manage to maintain PaX, we can indeed kiss hardened-sources > goodbye. and, of course :) grep -r -e paxmark -e pax_kernel /usr/portage/
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Mon, 1 May 2017 09:38:43 + Sven Vermeulenwrote: > The obvious step is indeed to stop further *current* development on > hardened-sources. I don't know how many additional patchsets are being > implemented in it (blueness? Zorry?) so I don't know if it means that > hardened-sources in total is done with or not. All patches in our current patchset (hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of them don't even touch the kernel code, but only the Kconfig's. So unless we manage to maintain PaX, we can indeed kiss hardened-sources goodbye. By the way: When switching over to gentoo-sources, please note that it applies some patches of its own (the genpatches.extras set, whereas hardened-sources only applies genpatches.base). Historically, this patchset has sometimes contained some weird (and probably totally unaudited) code. Currently it only contains two patches which look mostly safe, but it's probably a good idea to keep an eye on this patchset (or perhaps to use vanilla-sources?). Regards, Luis pgp9RN7hl63mr.pgp Description: OpenPGP digital signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project It closes the topic of our discussion. worth reading: http://openwall.com/lists/kernel-hardening/2017/05/01/5 http://openwall.com/lists/kernel-hardening/2017/05/02/4 this means: * KSPP means that keeping PaX for >4.9 will be difficult and painful, as I pointed out previously * NSA SELinux instead PAX MPROTECT? alternatives: RSBAC * slow, but actively developed: http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=summary * produkction ready * lots of options similar to what is in grsecurity (eg. restricted chroot in grsec and jail in rsbac): http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=blob;f=rsbac/Kconfig;h=4a6ae294d41365a5c1757503575074c89ceebb11;hb=HEAD
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
Shouldn't go to 4.10+, because it will be too much work. Best would be to maintain 4.9 LTS and not bother with 4.10 and all that. On 05/01/2017 04:53 PM, Daniel Cegiełka wrote: > 2017-05-01 16:20 GMT+02:00 SK: >> There is Subgraph that is going to keep maintaining 4.9.X LTS branch >> with grsec & there is minipli[1] that is going to forward 4.9.X LTS >> branch with grsec. >> >> Would be great to join forces to keep 4.9.X LTS alive while porting >> features upstream. > 4.9.* is not a problem, but >=4.10 requires a lot of work, and of > course there is a problem with the KSPP (links kernel.org) > > https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0 >
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-01 16:20 GMT+02:00 SK: > There is Subgraph that is going to keep maintaining 4.9.X LTS branch > with grsec & there is minipli[1] that is going to forward 4.9.X LTS > branch with grsec. > > Would be great to join forces to keep 4.9.X LTS alive while porting > features upstream. 4.9.* is not a problem, but >=4.10 requires a lot of work, and of course there is a problem with the KSPP (links kernel.org) https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
There is Subgraph that is going to keep maintaining 4.9.X LTS branch with grsec & there is minipli[1] that is going to forward 4.9.X LTS branch with grsec. Would be great to join forces to keep 4.9.X LTS alive while porting features upstream. 1. https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec On 05/01/2017 03:58 PM, Sven Vermeulen wrote: > On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote: >>> The obvious step is indeed to stop further *current* development on >>> hardened-sources. >> Why not support hardened-sources while corresponding vanilla >> kernels are still supported? E.g. 4.9 is a longterm branch, so we >> should be able to keep hardened-sources-4.9* up-to-date with >> vanilla bugfixes. This will give a nice transition period for >> hardened users. > Transition to what exactly? > > There is one suggestion that mentions we would join forces with other > projects "out there" to keep supporting the latest PaX patches. But this > will require knowledgeable resources with enough time to do the necessary > support on it. > > In my humble opinion, this is an effort which is not to be underestimated. > Maintaining the upstream-provided patches within Gentoo is already an > endeavour, and now we're talking about even taking on the patch content > itself as well. > > If we have enough volunteers to do so, then let's do it. At least we can > then have something for users to look forward to. If not, then the current > long-term branch is also the latest, and the "transition period" is to allow > users to move to a perhaps lesser kernel-hardened environment. > > Wkr, > Sven Vermeulen >
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote: > > The obvious step is indeed to stop further *current* development on > > hardened-sources. > > Why not support hardened-sources while corresponding vanilla > kernels are still supported? E.g. 4.9 is a longterm branch, so we > should be able to keep hardened-sources-4.9* up-to-date with > vanilla bugfixes. This will give a nice transition period for > hardened users. Transition to what exactly? There is one suggestion that mentions we would join forces with other projects "out there" to keep supporting the latest PaX patches. But this will require knowledgeable resources with enough time to do the necessary support on it. In my humble opinion, this is an effort which is not to be underestimated. Maintaining the upstream-provided patches within Gentoo is already an endeavour, and now we're talking about even taking on the patch content itself as well. If we have enough volunteers to do so, then let's do it. At least we can then have something for users to look forward to. If not, then the current long-term branch is also the latest, and the "transition period" is to allow users to move to a perhaps lesser kernel-hardened environment. Wkr, Sven Vermeulen
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-01 13:00 GMT+02:00 Andrew Savchenko: > Hi, > > On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegiełka wrote: > Are you sure PaX patches will be updated? Because PaXTeam claims > they will not be published [1]: (...) > Or do you suggest to support PaX with our own resources? https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
Hi, On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegiełka wrote: [...] > Summing up: > > * PaX is the most important part of Gentoo Hardened project > (Grsecurity, SELinux, RSBAC) > > * We can't use the 'grsecurity' name, which means that fork of > grsecurity == rewriting everything with 'grsecurity' (or 'grsec') > name... (~225k LOC grsec+PaX) > > * PaX (~176k LOC) is available as a separate patch (1), so we can use > it without the risk of 'grsecurity' trademark > > My opinion is: we should continue to use PaX patch and keep the Gentoo > Hardened project alive. > > (1) https://www.grsecurity.net/~paxguy1/ Are you sure PaX patches will be updated? Because PaXTeam claims they will not be published [1]: "As this is a joint decision, there will be no public PaX patches for future kernels. This is effective April 26th 2017." Or do you suggest to support PaX with our own resources? [1] https://grsecurity.net/passing_the_baton_faq.php Best regards, Andrew Savchenko pgpIgt51W1Eow.pgp Description: PGP signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
On Mon, 1 May 2017 09:38:43 + Sven Vermeulen wrote: > Hi all, > > There is a nice debate ongoing on the mailinglist [1] on the topic of > grsecurity's recent decision to no longer provide the test patches to the > public. I'd like to keep the debate on the rationale of it in that > discussion, but focus here on what we, from Gentoo Hardened, now need to do > or which direction we're going to move forward with. > > [1] > https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac > > The obvious step is indeed to stop further *current* development on > hardened-sources. Why not support hardened-sources while corresponding vanilla kernels are still supported? E.g. 4.9 is a longterm branch, so we should be able to keep hardened-sources-4.9* up-to-date with vanilla bugfixes. This will give a nice transition period for hardened users. Best regards, Andrew Savchenko pgpgkCaPB8J1s.pgp Description: PGP signature
Re: [gentoo-hardened] Technical repercussions of grsecurity removal
2017-05-01 11:38 GMT+02:00 Sven Vermeulen: > Hi all, > > There is a nice debate ongoing on the mailinglist [1] on the topic of > grsecurity's recent decision to no longer provide the test patches to the > public. I'd like to keep the debate on the rationale of it in that > discussion, but focus here on what we, from Gentoo Hardened, now need to do > or which direction we're going to move forward with. > > [1] > https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac > > The obvious step is indeed to stop further *current* development on > hardened-sources. I don't know how many additional patchsets are being > implemented in it (blueness? Zorry?) so I don't know if it means that > hardened-sources in total is done with or not. Hi, I have already written my opinion: https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb https://archives.gentoo.org/gentoo-hardened/message/139ab72c413b2b83e08c948b061882bf Summing up: * PaX is the most important part of Gentoo Hardened project (Grsecurity, SELinux, RSBAC) * We can't use the 'grsecurity' name, which means that fork of grsecurity == rewriting everything with 'grsecurity' (or 'grsec') name... (~225k LOC grsec+PaX) * PaX (~176k LOC) is available as a separate patch (1), so we can use it without the risk of 'grsecurity' trademark My opinion is: we should continue to use PaX patch and keep the Gentoo Hardened project alive. (1) https://www.grsecurity.net/~paxguy1/ Daniel