[22:08:05] 1.0 Toolchain [22:08:25] gcc 4.8 in in the tree but masked [22:09:28] it have some bugs 463564 and 458706 and the hardenedno* thing [22:10:10] on is fixed with a patch in gentoo patchset for gcc [22:10:20] which? [22:10:47] blueness: 463564 but i need to be fixed upstrem [22:11:04] have with missing header file for the plugins [22:11:17] oh the plugins [22:11:17] yeah [22:11:26] easy but very important fix [22:11:37] the next one is the asan thing that fail on both llvm and gcc 4.8 [22:12:05] Zorry: not missing me [22:12:07] Zorry, can we optionally turn off asan with a use flags? [22:12:14] car in the shop :( [22:12:29] asan is big and ugly and not something i want [22:13:08] blueness: we are two :( [22:13:25] so asan & klondike are big and ugly and not something we want? [22:13:26] blueness: don't think we can turn that off [22:13:30] :p [22:13:46] SwifT: I'm not that ugly :P [22:14:00] and that bug should be buged upstrem [22:14:39] Zorry, i didn't look at the configure options, but if its not there already then it sounds like they did a hard integration [22:14:46] and it might be hard to turn off asan support [22:14:58] do we want to turn it off? it's touted as a nice security feature [22:15:05] it doesn't change the binaries produced, but it makes building gcc 4.8 crazy [22:15:13] SwifT, it is? [22:15:13] is not in the configure options [22:15:33] SwifT, maybe a diagnostic for security, but not security per se [22:15:40] SwifT: having a server disconnected inside a bunker is secure too but gives you problems when people wants to use it [22:15:50] http://www.internetnews.com/blog/skerner/open-source-gcc-4.8-compiler-including-address-sanitizer-security.html [22:16:05] not saying that what's on the internet is true, but it's PR :p [22:16:37] AddressSanitizer is a detector [22:16:41] SwifT: asan has hardcoded defaults assuming the usual 47 bit linux/amd64 userland address space size [22:16:43] there are others [22:16:49] is the prob [22:17:12] yeah that's *hardware* addressing not the 64-bit virtual addressing [22:17:28] oh wait, maybe not [22:17:43] Zorry, so does it split the address space in half? [22:17:59] I think so [22:18:27] So a half of a half is a quarter :P [22:18:31] blueness: the prob is that pax/grsec dont use all the 47 bit userland [22:18:32] yeah what i said is wrong, its the 48-bit virtual address space -> one bit set aside [22:19:25] Zorry, so we can't compile with gcc-4.8 with a pax hardened kernel? [22:19:48] blueness: we can but we cant use the asan [22:20:07] so currently gcc-4.8 builds in asan support (which takes a while) but we can't use it, right? [22:20:09] fine, i can live with that [22:20:16] SwifT: yep [22:20:21] gotit, thx [22:20:31] yeah twice the resources for no gain [22:20:44] Zorry, does it just silently fail? [22:21:28] blueness: ERROR: AddressSanitizer failed to allocate 0x20000001000 (2199023259648) bytes at address 0x0ffffffff000 [22:21:41] got it [22:21:55] for it asume things [22:22:15] Zorry: I recall in LVM they propossed lowering the number of bits in the address space [22:22:32] The worst you'll get is less virtual memory :P [22:22:49] is work on the way to get either (pax/grsec or asan) to the state that they will play together? [22:23:10] klondike: yes but then you get prob when not runing h-s kernel [22:23:13] can't find anything when searching for "pax grsec asan" [22:23:39] Zorry: which kind of problems? [22:23:41] SwifT: read comment 16 [22:24:09] !bug 463564 [22:24:11] klondike: https://bugs.gentoo.org/463564 "sys-kernel/hardened-sources fail to compile on gcc-4.8.0 missing target.h"; Gentoo Linux, Hardened; RESO, FIXE; zorry:hardened [22:24:16] klondike: comment 16 [22:24:20] !bug 458706 [22:24:22] klondike: https://bugs.gentoo.org/458706 "PaX: Max. per-task virtual memory too small for llvm asan and gcc-4.8 asan"; Gentoo Linux, Hardened; UNCO; klaus.kusche:hardened [22:24:54] klondike: with h-s you have one address spec and with out you have a diffrent [22:26:28] Zorry, are we ready to move on because i have something to say about gcc-4.8 + uclibc + minor arches [22:26:46] blueness: yes go on [22:26:51] Oh cool [22:27:09] Zorry, okay so there are problems with gcc-4.8 as discussed but there are definitely some good things [22:27:23] amd64 and i686 uclibc + gcc-4.8.0 work perfectly, no problems [22:27:32] well not the hardenedno, but that's a different issue [22:27:43] armv7a uclibc + gcc-4.8.0 works good [22:28:02] and the most important one was mips because it was hacky before 4.8 [22:28:30] so gcc-4.8.0 with glibc or uclibc on mips or mipsel work great [22:28:31] all abis [22:29:04] so from my point of view, except for the problems mentionsed, I don't need any extra hacks to get gcc-4.8 to work on my stuff [22:29:11] and of course, full userland hardening [22:29:21] so we're moving in the right direction [22:29:51] oh Zorry one more question about asan, i just thought of it, sorry out of order [22:30:02] go ahead [22:30:23] if you compile userland under a vanilla kernel and then use pax-enable kernel, is there any problem, like are the limits to vm permanent? [22:30:56] (i need to do some experimentation) [22:31:17] blueness: it will be probs for the addres specs differs and it use hardcodec adresses [22:31:31] blueness: VM limits are set by the task size on the kernel [22:31:37] as saind in the comment 16 on the bug [22:32:00] they usually depend on the processor so the problem is these are hardcoded as Zorry said [22:32:12] klondike, i know but if there are hard coded addrs thenwe have issues [22:32:23] k [22:32:52] blueness: don't build your userland with -fsanitize=address and I think asan isn't used then [22:32:55] blueness: the question is more like ¿How much can they be unhardcoded? [22:33:01] SwifT: +1 [22:33:21] blueness: is not on ass default [22:34:02] and should only be just for debuging for it is a big performens hit [22:34:57] any one else ? [22:35:06] Me [22:35:22] About the blessed libffi [22:35:34] klondike: take that on bugs? [22:35:58] I have been doing some research and I think I can write some code to detect trampolines on all circumstances [22:36:12] Only problem is that I will need some assembly love [22:36:20] just that :) [22:36:51] next [22:37:00] oki [22:37:05] 2.0 Kernel and Grsec/PaX [22:37:33] okay [22:37:49] I stabilized some recent kernels [22:38:15] there weren't too many bugs but i want to keep as close to grsec/pax upstream as possible [22:38:22] we're at 2.6.32-r156, 3.2.40-r1, 3.8.3 [22:38:40] no serious bugs out, one which is a vanilla bug and i will submit a report upstream [22:38:42] next [22:38:50] the big one is the XATTR_PAX issue [22:39:12] currently there are two issues that need to be cleaned up before we can fully use XATTR_PAX [22:39:50] 1) on non-hardened systems, users get warnings that pax-mark can't set XATTR_PAX on tmpfs because vanilla tmpfs does not support user.* namespace [22:40:16] so the solution there, in my opinion, is to isolate the user.* namespace xattr pax and include it in gentoo-sources [22:40:39] it is a pretty safe patch, but I doubt it will be accepted upstream because there is no other pax support in the vanilla kernel [22:40:54] 2) the other problem we found was when pax-marking is done [22:41:24] coreutils, even with xattr support, does not give install which copies xattr the way cp does [22:41:42] blueness: user xattrs are not PaX only :P [22:42:01] i know how to hack the C code to fix that, even conditionally with a flag, but i'm still thinking about how to organically include that [22:42:09] klondike, yeah, like CAPS [22:42:32] so right now, any pax markings done during src_install before install fails to get copied to the filesystem [22:42:41] while any pax-marking done after works [22:42:59] we could ask people to do pax-marking lafter install [22:43:18] like make pkg_postinst() but then there are somethings that need pax-markings before install for tests [22:43:44] blueness: the prob is when we need it to in compile or test [22:43:49] i'm not sure, what do people think is best? patch install or try to get pax-mark done after make install? [22:43:54] right [22:44:01] we need it early [22:44:05] you could do pax-mark twice [22:44:09] that's ugly [22:44:32] could write a test for in the post phase, then fix any missed marks [22:44:33] or i could do what some of the other eclasses do [22:44:52] hi, btw [22:44:54] :) [22:45:02] Hi summers [22:45:17] well i was thinking if you create a bash array of elfs to be pax marked, then you can use a default in each phase and "remark" [22:45:26] makes sense [22:45:45] i don't know, my preference is to make cp and install and all coreutils just copy xattr automagically if USE=xattr. [22:45:48] some will require marks in test phase [22:45:55] I don't now how the rest of the community would like that [22:45:59] hi matt! [22:46:02] :) [22:46:51] blueness: we need some fix now but upstream may need some else fix [22:47:05] don't let me forget to ask about pax-marking python when the Q&A period starts [22:47:17] blueness: I at leas like it [22:47:19] Zorry, okay i can produce a fix now with coreutils, but just one question .... [22:47:46] right now with USE=xattr, to get xattr copied with cp you need to do "cp -a" [22:48:00] i can hack up install so that to get xattr copied you do "install -a" [22:48:08] ohnoes... not -a [22:48:23] but most of the Makefile just have install [22:48:44] blueness: selinux have -Z ithink [22:48:50] should i just drop the flag and make it automatically cp xattr so the new cp will work like "cp -a" [22:48:51] blueness: if you use "cp -a", please use "cp -a --no-preserve=context" [22:49:23] SwifT, Zorry i'll come up with a good name for a flag later the question but the question is, do we even want a flag or just to do it automatically? [22:50:04] for the pax markings, I don't think there is a problem with automatically doing that (if the target supports xattr, of course) [22:50:09] i guess the point is, will the build systems out there inherit the correct flags? Say the flag is -X, how do we get all the build systems to do INSTALL="install -x" [22:50:10] ? [22:50:13] but only pax marking, not all xattrs [22:50:38] SwifT, so check if the xattrs is "user.pax"? [22:50:45] looks too hacky [22:50:59] maybe then USE="pax_kernel" on coreutils enable this automatically [22:51:13] SwifT: Does selinux still required python-2? [22:51:19] yes; the security.* xattrs are usually protected differently; security.selinux will require label rights (which you won't always have), security.evm will break (since these need to be recomputed) and security.ima might break (depending on used algo) [22:51:43] blueness: yes some thing like that [22:51:44] jmbsvicetto: some stuff does, other doesn't [22:52:30] okay ... here's the plan then, add USE="pax_kernel" to coreutils, when compiled, cp, mv, install and friends will all copy "user.pax" without needing any extra flag. Correct? [22:53:08] +1 [22:53:22] +1 [22:53:33] +1 [22:53:42] okay guys, it works for me, but klondike's point is well taken ... it will leave other xattrs out [22:53:58] final point, for the next 3 weeks i will be in hell! [22:54:09] *cough* [22:54:13] as the semester ends, after that, i will hack evertying together [22:54:24] SwifT, i've already given up sleep! [22:54:33] lol [22:54:38] from 3h sleep to zero... :p [22:54:56] maybe if i stop shaving i can gain another 5 minutes a month [22:55:02] :) [22:55:02] blueness: don't worry, we'll cover your back :P [22:55:16] klondike, cover my back with eudev, no one is helping there! [22:55:20] blueness: I stopped shaving, didn't regret it xD [22:55:22] that's what ate up my time [22:55:33] klondike, but you don't mind being ugly! :) [22:55:42] -*- blueness runs [22:55:47] -*- klondike is scared of eudev xD [22:56:04] blueness: sticks and stones :P [22:56:15] I'd say we can go for next though [22:56:18] klondike, why, i got it working [22:56:22] we're at 200 [22:56:23] blueness: +1 to no shaving [22:56:40] next ? [22:56:45] okay next [22:56:51] 3.0 Selinux [22:56:54] yes, enough talk about depilification [22:56:56] go! go! go! [22:57:19] ok, most userland utilities have seen some patches... setools-3.3.8 is now in the tree (sorry, no swig fix) [22:57:51] policycoreutils now also provides the selinux_gentoo init script, needed to support relabeling /dev (and initramfs spport if you're a special guy) [22:58:16] libselinux has been bumped to support udev-200 (never thought udev would go this deep :p) [22:58:51] for portage, use="python2" has been removed so the selinux-suppor in portage now handles python3 nicely [22:59:02] (special thanks to the portage herd for their fast patching/releases) [22:59:31] policy-wise, we're now at rev12. lately, most changes upstream on the policies have been ours (little feedback from others) [22:59:52] i'm prepping rev13 but as most fixes are already available in the live ebuilds, i'm not pressured :p [23:00:28] the selinux eclass has been fixed to make multiple policy stores more intelligent (mixing unconfined with strict gave weird situations in the past :p) [23:00:55] also, I round out why I couldn't have service scripts executed without password change [23:01:06] made a nice blogpost for it, and put the fix in our repository ;) [23:01:08] SwifT, when you're done with your summary tell me about the udev-200 changes [23:01:55] ok, was just done (all the rest is docs)... the udev-200 change I had to do on libselinux was to update on error/return codes. udev is selinux-aware, and it looks like the calls to libselinux needed some return code fixes in libselinux [23:02:19] ssuominen provided me with the needed patch, so it was just putting it in the patch bundle [23:02:40] oh, almost forgot, some sad news as well [23:02:55] pebenito is no longer registered as a developer :-( [23:03:27] infra retired him, but I put him on our project page in the "hall of fame" [23:03:47] :) [23:04:02] that's it for selinux [23:04:15] Sad to see pebenito away [23:04:15] any one else? [23:04:16] SwifT, okay so its the selinux awareness that you need [23:04:34] i asked because i removed all selinux awareness from eudev, its neutral in that respect [23:04:57] systemd in general is isolating choices, this is yet another example [23:04:58] too bad, but I can understand it [23:05:21] SwifT, we want ot be neutral with respect to security models, "one thing well" [23:05:40] udev selinux support is needed to get the proper contexts on the device files early. perhaps with the selinux_gentoo init script that might not be needed; i'll need to check [23:05:46] right [23:06:07] suppose udev did not set early contexts, would things break for you? [23:06:09] i'm definitely pro neutrality on that part... selinux-aware applications are much harder t debug :p [23:06:41] next ? [23:06:43] yes... console wouldn't work, initctl wouldn't work, etc [23:06:50] yup, next [23:06:54] okay next [23:06:59] 4.0 System Integrity [23:07:53] nothing significant here; the patches needed to get IMA/EVM working with SELinux have been sent to the linux-security-whatever mailinglist for inclusion [23:08:23] brb [23:08:32] I'm not able to keep my VMs alive with EVM in enforcing mode for long, so currently testing is done with EVM=fix. we did found out why though - also sent upstream [23:09:08] that's it for integrity [23:10:33] next [23:10:43] 5.0 Profiles [23:10:59] don't have anything [23:11:28] -*- SwifT neither [23:11:40] Zorry, nothing new really, just that we made the global switch to 13.0 and no screaming [23:12:26] Sorry I am late as hell, but my schedule, for big part the same reasons as blueness, are completly screwed up the past weeks and coming month [23:12:32] I recall something [23:12:48] lejonet: read backlog :P [23:12:52] klondike: already done :) [23:13:14] blueness: wasn't there an issue with inheritance and uses disabled or something [23:13:29] I recall it was brought up on the channel and I pointed the user to you [23:14:13] klondike, oh with uclibc, ulm [23:14:20] yeah i did a daring thing with those profiles [23:14:25] i'm afraid to tell people :) [23:14:30] lol [23:14:33] i made them very shallow [23:14:41] so i skipped profile/arch [23:14:49] It's not as if I'm tweeting this :P [23:15:07] the reason is this, profile arch is to tweak on the basis of architecture with the assumption of glibc [23:15:19] (tweat it, i was being melodramatic) [23:15:46] Did so :P [23:15:53] but i think that it is better to collapse arch + libc into one level [23:16:09] so these profiles inherit directly from base, and skip everything else [23:16:41] so ulm's question, he wanted to mask something and didn't know where to mask it because there was no arch layer [23:16:58] so i said, go ahead and mask that the lowest leve, ie hardened/linux/uclibc/ [23:17:18] i don't know how people feel about that, its kinda like what embedded does only less sever [23:17:30] profile/embedded doesn't even inherit from base [23:17:37] comments? [23:17:58] Not from me profiles give me headaches [23:18:00] /usr/portage/profiles/base [23:18:00] /usr/portage/profiles/default/linux [23:18:00] /usr/portage/profiles/hardened/linux/uclibc [23:18:00] /usr/portage/profiles/hardened/linux/uclibc/amd64 [23:18:00] /etc/portage/profile [23:18:14] ^^^ this is hardened/linux/uclibc/amd64 [23:18:24] it skips profile/default and profile/arch [23:18:51] changes that would be made in profile/default and profile/arch are collapsed down to hardened/linux/uclibc/amd64 [23:19:16] next? [23:19:30] if no one wants to flame me :) [23:19:36] next [23:19:44] blueness: this is friend zone [23:19:49] 6.0 Docs [23:19:52] No flames or I'll get the kickhammer :P [23:20:04] :) [23:20:22] for SELinux, USE="unconfined" is documented in the handbook [23:20:57] I also included info on the selinux_gentoo init script in the installation instructions; of course, also the "Changes" chapter at the end of the SELinux handbook covers that as well (so that people already running with SELinux can just look at the changes at the end) [23:21:17] I also started with a tutorial spree on th gentoo wiki about selinux -> https://wiki.gentoo.org/wiki/SELinux/Tutorials [23:21:25] i hope to do a few more tomorrow about policy development [23:21:42] I also started writing DOMAIN_selinux manpages, which will be installed with selinux-base on the system [23:21:45] Oh boy! Tuts! [23:22:14] unlike fedora, who generates the man pages automatically, I tend to do it mannually as i'm afraid that there is no other way to properly document it in an automated manner [23:22:38] people who use selinux-base-9999 can see this for instance "man portage_selinux" or "man aide_selinux" [23:22:58] finally, I also documented AIDE on the gentoo wiki (Advanced Intrusion Detection Environment application, very nice to play with) [23:23:09] that's it for hardened docs [23:23:27] well i have some stuff [23:23:43] i got a bug about the grsec2 document [23:23:58] apparently it has some stuff about pax marking which is way out of date and still talks about chpax [23:24:14] i haven't gotten to it, but that should be removed and a link placed to the new documents [23:24:26] the new documents need some tweaking as we make bug fixes to XATTR_PAX [23:24:43] but i'm hodling off on those changes until its done [23:24:51] anything else? [23:25:15] not on my part [23:25:45] next then? [23:25:57] blueness: can you fill a bug, I'll remove references to chpax [23:26:30] klondike, the bug already exists [23:26:51] But is not assigned to me, I'll look for it then [23:26:57] We can go for next [23:26:58] https://bugs.gentoo.org/show_bug.cgi?id=352815 [23:27:26] 7.0 Bugs [23:27:26] assigned to you [23:27:29] when can we stop pax marking python??!!!???!!!!?????!!!!!!??????? :-D [23:27:45] summers, lost cause my friend [23:27:53] summers: it need emutramp enable [23:27:53] never [23:27:58] Thanks tony :D [23:27:59] no biggie [23:28:14] summers: the main prob is the libffi thing [23:28:23] libffi yep [23:28:26] I'm working on it [23:28:32] I thought there were fixes that went in last few months [23:28:41] I think I can get a propper detection even for chroots when /proc is not there [23:28:43] they were Arach's emultrap thingy [23:29:07] sad story [23:29:09] summers: the fixes have issues don't work well between hardened and not hardened systems [23:29:21] gotcha [23:29:26] summers: yes but it fail if you change to no pax kernel with out recompile libffi [23:30:26] summers: and it still on unstable [23:30:35] that could prove difficult with broken python ... ok, thanks for teh update [23:31:06] summers: we will fix it when libffi works as it should [23:32:07] Zorry, i'm sorry i forget the failure path with libffi, wasn't it trying to generate code on the fly in /tmp? [23:32:14] summers: python is not the only one that have probs with libffi look at gnome [23:32:31] blueness: it use mmap rwx [23:32:46] terrible [23:33:04] Zorry, yeah but if i recall correctly, doesn't it generate tmp code with rwx mmaP? [23:33:26] blueness: if mmap fail it try to use /tmp stuff [23:33:30] right [23:33:34] so it real ugly [23:33:40] so can't we make that our workaround? [23:33:57] blueness: i don't want to have exec on /tmp [23:34:11] well no not in /tmp but maybe somewhere else [23:34:14] if /tmp fails it tries in the user home dir [23:34:25] it try allover the plases [23:34:27] selinux continuously blocks it :;p [23:34:42] it's so ugly, my brain almost removed my memories of it [23:34:45] blueness: TPE will jump in and screw you :P [23:34:56] from libffi's point of view, it needs to generate executable on the fly, that's what its main purpose is, as a for library compat bridge [23:34:59] and a read only system [23:35:22] blueness: all it needs are trampolines [23:35:28] That's a mov and a jmp! [23:35:49] i guess that's Arach's solution then [23:35:54] -*- klondike has been reading the kernel code to understand trampoline emulation :P [23:36:01] and to fall back on the kernel's tramp code [23:36:03] blueness: Arach solution is marking all RW [23:36:17] This fails obviously on non hardened kernels [23:36:34] So still some work needs to be done [23:36:45] so wait, is then the problem is jsut making sure we don't fail on vanilla which is missing tramp emu code [23:36:47] bedtime; thanks folks, great job! http://blog.siphos.be/2013/04/another-gentoo-hardened-month-has-passed/ (+ thanks to klondike for tweeting ;) [23:36:56] blueness: we allready have fix but it works but you can't change to no hardened [23:37:11] blueness: yes [23:37:11] so try if( mmap( some bogus stuff ) == failure { then check if pax and use emu tramp } [23:37:27] blueness: then your logs get polluted :P [23:37:31] Zorry, okay now its coming back to me [23:37:38] So I'm trying the reverse approach [23:37:51] Try a trampoline on RW catch the SIGSEGV [23:38:18] and then catch the signal? i'm not sure i like that other things cause SIGSEGV [23:38:53] blueness: welcome to java world :P [23:38:54] so mask signals before your check, do your check, then unmask ... not sure [23:39:19] klondike, well wait maybe your solution can work, so you set up your signals before your test which you do once and only once [23:39:23] But this is only made if hardened support is needed :P [23:39:24] then you tear your signals down [23:39:30] yep [23:39:35] And restore the old handler [23:39:46] klondike, once it is compile you want to be able to switch hardened/vanilla with no issues [23:40:14] okay that can be done, but i still think you can do it with the mmap failure just once [23:40:16] blueness: and so it will do [23:40:24] is only needed when we can't read /proc/self/status [23:40:38] blueness: the problem is that it will still pollute the logs [23:40:49] And as said the option we choose is only when /proc isn't there [23:40:59] klondike, i'd rather live with that the have complex signaling code [23:41:14] bah! /proc needs to be there for lots of other reasons [23:41:28] you can expect lots of breakage if /proc is not there on either hardened or not [23:41:32] -*- klondike thinks on paranoid chrooters [23:41:34] so that's a safe assumption [23:42:06] yeah chroots with no apache, or apache with no semaphores, its still very very restricted [23:42:14] -*- summers has derailed the meeting. Apologies. [23:42:21] summers: cu [23:42:30] no this is an important design question [23:42:31] this is just an issue that sticks in my mind [23:42:37] we need something here we can live with [23:42:46] its the bug that will not die [23:42:50] I agree, how things got to this really tweak my understanding of tings [23:43:00] *things [23:43:13] poor prog practice for the libffi peeps [23:43:34] the fundamental problem for hardened pax is that we don't want to allow code to be generated on the fly but some things need to generate code on the fly [23:43:58] how do we safely deal with that, and i think stearing them to the kernel's emul tramp code is correct [23:43:59] trampolines for example [23:44:25] There is also JIT, pipacs said he had something but... [23:44:38] okay klondike, give a shot to the signaling code, and ping me in about 3 weeks and we'll nail this bastard once and for all [23:44:47] woot [23:44:53] Oki blueness [23:45:14] guys i've got ot run [23:45:20] we're about done? [23:45:28] blueness: yes most done [23:45:36] I think sp [23:45:57] On 8 media just that we tweeted the meeting, no talks scheduled for now I think [23:46:08] later everyone, sorry i have to skip out now [23:46:12] klondike: blueness it need to be tested on gnome to and there we have works/noworks [23:46:33] cya blueness [23:46:49] next 8.0 Media [23:46:55] Zorry: there we'll still need paxmarks, we can use revdep-pax for these though [23:47:22] just that we tweeted the meeting and there is no talks scheduled for now I think [23:47:25] klondike: it is allready have -m on the bin that need it but no E yet [23:47:49]