Agenda for the meeting 1.0 Toolchain 2.0 Kernel and Grsec/PaX 3.0 Selinux 4.0 System Integrity 5.0 Profiles 6.0 Docs 7.0 Bugs 8.0 Media 9.0 Open floor /Magnus
[21:16:00] <Zorry> 1.0 Toolchain [21:16:15] <Zorry> not that much new stuff [21:16:54] <Zorry> will fix up some patches so we can enable ssp as default in the toolchain [21:17:41] <Zorry> blueness: do you have annything? [21:17:52] <blueness> not really [21:18:14] <blueness> i've just been maintaining the uclibc stags, but nothing new [21:18:42] <blueness> i do have a question though [21:18:57] <Zorry> go [21:19:00] <blueness> so asan stuff, still the same situation as last month? [21:19:06] <Zorry> yes [21:19:11] <blueness> okay [21:20:02] <alsoSwifT> next? [21:20:06] <Zorry> next [21:20:06] <blueness> yes next [21:20:23] <Zorry> 2.0 kernel Grsec/PaX [21:20:41] <blueness> okay a few things [21:20:43] <prometheanfire> people are asking, so I'll ask [21:20:44] <prometheanfire> lts? [21:20:56] <blueness> not sure [21:21:15] <prometheanfire> just wanted it official, thanks [21:21:27] <blueness> 3.12 is lts at kernel.org but i don't know whether or not spender will maintain it lts [21:21:40] <blueness> err .. wait no [21:21:48] <prometheanfire> upstream goes off of ubuntu lts [21:22:04] <blueness> 3.10 is lts and it is not maintained by grsec pax [21:22:11] <blueness> whether 3.12 will be i 'm not sure [21:22:37] <blueness> okay let me get my couple of points out [21:22:45] <blueness> 1) grsec-3.0 is out [21:23:00] <alsoSwifT> \o/ [21:23:07] <blueness> the latest kernels are grsec-3.0, and they require gradm-3.0 [21:23:32] <blueness> it was a rough start but the kernels in the tree now are okay for at least testing [21:23:36] <blueness> earlier once were panicking [21:23:53] <blueness> i'll be stabilizing one of ht elast 2.9.1's in a few days [21:24:22] <blueness> 2) install.py wrapper. i've started work on the c wrapper version of that [21:24:33] <prometheanfire> I'm running 3.12.4 without issue (without grsec rbac) [21:24:43] <blueness> becuase install.py is too slow for large number of files [21:25:05] <blueness> so i'm hoping by next month i can get the portage team to switch out install.py for my compiled version [21:25:17] <blueness> the compiled version should be much faster [21:25:32] <blueness> but i won't know for sure until i've finished writing it [21:25:54] <blueness> hi pipacs [21:26:00] <blueness> okay that's it for me [21:26:03] <blueness> questions? [21:26:03] <Zero_Chaos> sorry, internet bad at 587mph. [21:26:06] <pipacs> evening, sorry for being late [21:26:12] <Zorry> pipacs: np [21:26:21] <blueness> pipacs, no problem i just menitons spender's up to grsec-3.0 [21:26:23] <pipacs> but let me know if i was needed for something ;P [21:26:25] <blueness> mentioned [21:26:52] <blueness> pipacs, do we know the next lts after 3.2? [21:27:06] <blueness> lts both kernel.org lts + grsec/pax lts [21:27:18] <pipacs> not yet, we try to follow ubuntu lts, which at the moment looks like to be based on 3.13 or perhaps 3.14 [21:27:40] <blueness> yep [21:28:00] <blueness> okay i'm finished if there's nothing more [21:28:24] -*- blueness runs downstairs for a hot cup of coffee [21:28:31] <Zorry> next [21:28:49] <Zorry> 3.0 SeLinux [21:29:09] <alsoSwifT> our live policies are well uptodate with upstream, and i pushed out rev 5 to the tree a few days ago [21:29:11] <prometheanfire> steev: arm status? [21:29:37] <alsoSwifT> also, we have the latest userspace in the tree as well [21:29:38] <steev> arm status is that i need to test a few other machines, but it works afaict, which, i still haven't finished swift's book so i'm not 1000% sure [21:30:03] <alsoSwifT> steev: well, once its finished give me a hurl and I'll tag all selinux packages for arm [21:30:20] <steev> need to keyword it though, and i should ask the other arm team members about it, since i do believe it will require setting the policy version manually [21:30:22] <alsoSwifT> i'm still hoping to have an arm system for me by the end of next week as well for teting [21:30:26] <steev> since arm kernels tend to be... older [21:30:26] <Hello71> *holler? [21:30:47] <alsoSwifT> we can document that (the version thingie) [21:30:50] <steev> alsoSwifT: i can give you access to one, if you don't have any (and please please, tell me you're getting a real arm system, and not an rpi and calling it an arm system) [21:31:03] <prometheanfire> zfs also seems to work now, the patchset is in (as of about an hour ago) [21:31:14] <alsoSwifT> it's a ubiquity or whatsitcalled [21:31:22] <prometheanfire> I need to submit a patch to refpol, but it's simple [21:31:28] <steev> ubiquity is a wifi dongle [21:31:35] <alsoSwifT> ah something else then :p [21:31:37] <steev> parallax thingie? [21:31:51] <steev> http://www.parallella.org/ ? [21:32:02] <alsoSwifT> i'll get back on you later what it is- don't have the papers here atm [21:32:07] <alsoSwifT> not parallella, nox [21:32:15] <steev> ok [21:32:30] <alsoSwifT> anyway, userspace utils are in tree, upstream was quite happy to take a lot of our patches in [21:32:36] <steev> good eal [21:32:37] <steev> deal* [21:32:53] <alsoSwifT> so the latest upstreamonly has a very few gentoo-specifics in in (mainly sandbox -> sesandbox stuff) [21:33:15] <alsoSwifT> i do need to stabilize the r5 policies before userspace stabilization as there are changes in behavior that need to be allowed [21:33:28] <alsoSwifT> but that shouldn't be a problem [21:33:42] <steev> alsoSwifT: it should be noted that for arm, very few things are/have been tested/installed [21:33:48] <steev> but the basics definitely seem to work [21:33:58] <alsoSwifT> as a last point, the selinux eclass was also updated to allow for live ebuilds from the HTTP git interface (got a bug on that) [21:34:09] <prometheanfire> nice [21:34:25] <alsoSwifT> steev: that's ok, i'm notgoing to mark it arm-stable (i don't even think there is an arm-stable keyword) [21:34:47] <steev> arm does stable, yes [21:35:36] <blueness> back [21:35:53] <alsoSwifT> that's it for selinux [21:36:00] <alsoSwifT> (from my ppart) [21:36:01] <prometheanfire> done here as well [21:36:15] <steev> done too i guess [21:36:27] <blueness> alsoSwifT, i didn't know you were moving for arm [21:36:35] <blueness> i can help there, i've got some arm devices [21:36:54] <alsoSwifT> i know, i just need to find more free time ,) devices isn't an issue [21:37:02] <blueness> what i? [21:37:04] <blueness> what is? [21:37:08] <steev> TIME [21:37:11] <steev> as always [21:37:26] <alsoSwifT> yes [21:37:37] <alsoSwifT> and preferably before noon :p [21:37:41] <alsoSwifT> otherwise i'm too tired [21:37:42] <blueness> what is the tehcnical issue? [21:37:50] <blueness> do we need testing? [21:38:10] <steev> blueness: after the meeting [21:38:17] <blueness> steev, k [21:38:21] <blueness> neeeext! [21:38:57] <Zorry> 4.0 System Integrity [21:39:05] <alsoSwifT> nothing major here; ima/evm still work well on the 3.11 kernel series, as does signed kernel module support [21:39:23] <alsoSwifT> no upstream changes, so not that much work beyond maintenance ;) [21:40:07] <blueness> alsoSwifT, what's required there [21:40:13] <alsoSwifT> i'm going to work on a gentoo security benchmark (using SCAP) in the next few days, you'll see lots of blog posts pertaining to it [21:40:42] <alsoSwifT> it's mostly regression testing with IMA/EVM, checking that TPM drivers still work, policies still load, etc. [21:40:54] <blueness> i see [21:40:59] <alsoSwifT> but ever since 3.8 i had no problems with it [21:41:09] <alsoSwifT> almost boring [21:41:11] <alsoSwifT> :) [21:41:38] <alsoSwifT> that's it for integrity from me [21:41:57] <Zorry> next? [21:42:18] <Zorry> 5.0 Profiles [21:42:26] <blueness> okay [21:42:36] <blueness> i looked into the destkop profile issue [21:43:05] <blueness> and i think the best thing, if we want is to maintain a second set of "target" profiles ourselves [21:43:13] <blueness> so to remind you of the issue [21:43:28] <blueness> Zero_Chaos, wants to reindroduce hardened/amd64/dekstop [21:43:35] <blueness> also x86 and arm [21:43:57] <Zero_Chaos> I would prefer to fix the bug in portage which breaks the profiles in an insane fashion [21:44:02] <blueness> but the way inheritance works it either puts default/targets after hardned [21:44:03] <Zero_Chaos> rather than have our own [21:44:14] <blueness> Zero_Chaos, actually that would be best [21:44:37] <blueness> so can you spearhead that and see [21:45:18] <blueness> in the mean time, i'm going to remove the ancient /developer and /server since there is no request for htose and they are deprecated since jan 2013 [21:45:25] <Zero_Chaos> blueness: yeah, just as soon as we have a portage maintainer again :-( [21:45:27] <blueness> i'll leave /desktop pening [21:45:30] <blueness> pending [21:45:45] <Zero_Chaos> blueness: you can remove all the deprecated profiles imho, they do noone any good at this time. [21:45:56] <blueness> Zero_Chaos, i did think of adding something like a cut [21:46:03] <blueness> Zero_Chaos, okay i'll remove /desktop too [21:46:27] <blueness> "cut" so imagine a syntax like ... !../../target/desktop [21:46:30] <blueness> with an ! in front [21:46:46] <blueness> which says inherit ../../target/desktop but no deeper than one level [21:46:56] <blueness> i can see how to implement that in portage [21:47:39] <blueness> that would allow you to stack profiles one level deep without inheriting all the way back to base each time [21:47:46] <blueness> what do you think? [21:47:59] <blueness> (the idea was inspired by prolog) [21:48:06] <blueness> Zero_Chaos, ^^?? [21:48:11] <alsoSwifT> what about implementing desktop stuff as a profiles/features one? [21:48:36] <blueness> alsoSwifT, well as long as we control it yes, like we did with selinux [21:48:42] <Zero_Chaos> blueness: honestly if you look at the profile stacking order in your tests, the error makes no sensense at all. [21:49:21] <blueness> Zero_Chaos, it is reproduceable and it does make sense because last profile wins [21:49:49] <blueness> alsoSwifT, the issue with selinux was that it was orthogonal to the hardened stuff [21:50:04] <alsoSwifT> ok [21:50:07] <blueness> so adding it as a feature was perfect [21:50:35] <Zero_Chaos> blueness: that's the thing, from the point where you edit the profile , the two profiles are identical. so in this case, the last profile isn't winning, something odd is happening [21:50:38] <blueness> but with desktop we have USE flags, package maskings and package.use that are in conflict with what harened requires [21:51:19] <blueness> alsoSwifT, damn lost him [21:51:24] <blueness> Zero_Chaos, did you reproduce it? [21:51:58] <Zero_Chaos> blueness: I haven'te even slept in 3 months honestly. [21:52:21] <blueness> alsoSwifT, back to the orthogonality issue [21:52:42] <blueness> the way selinux was stacking before lead to the US=mutlilib clash [21:52:50] <blueness> we are in the same situation with the desktop profile [21:53:38] <blueness> there are only two ways out: 1) fix portage to stop the recursive stacking so we have better control, 2) create our own hardened/targets that we manually keep orthogonal [21:54:16] <blueness> but having the current stacking mix means that changes to the middle stacks will change the final profiles we push out without our control [21:54:50] <blueness> which can break hardened user's systems even with the best of intentioned changes to the middle stack layers [21:54:59] <blueness> dman lots swift again! [21:55:30] <blueness> my last message to you [21:55:38] <blueness> SwifT, which can break hardened user's systems even with the best of intentioned changes to the middle stack layers [21:56:01] <blueness> SwifT, anyhow that's what happened with selinux + multilib the old way [21:56:16] <SwifTy> but what do users expect from a "desktop" profile other than a few use flags? [21:56:26] <blueness> a change in the middle layers after that stack had been set up cause selinux amd64 no-mutlilib to break without our having done anything [21:56:49] <blueness> SwifT, there are some force used flags, eg libxml2 needs python use forced [21:56:57] <Zorry> SwifTy: most use flags stuff [21:57:15] <blueness> yeah but even the use flags are a problem, eg USE=jit or orc [21:57:26] <SwifTy> right [21:57:50] <SwifTy> features/hardened_desktop then p [21:57:52] <SwifTy> ;p [21:57:59] <blueness> SwifT, i really like the idea of fixing portage, but i think Zero_Chaos and I think there are different things to be fixed [21:58:08] <blueness> SwifTy, that's what i was thinking [21:58:18] <blueness> or profiles/hardened/targets [21:58:23] <blueness> where we can put our own targets [21:58:44] <blueness> SwifTy, 1 sec, let me show you the bug [21:59:03] <SwifTy> blueness: i'm on cli only [21:59:04] <blueness> bug #492312 [21:59:05] <willikins> blueness: https://bugs.gentoo.org/492312 "Reintroduce hardened desktop profiles"; Gentoo Linux, Eclasses and Profiles; CONF; zerochaos:hardened [21:59:20] <blueness> SwifTy, ^^^ well there it is [21:59:25] <SwifTy> i'll read up on it tomorrow when i draft up the blog post summarizing this meeting :) [21:59:47] <blueness> SwifTy, yeah i was actually thinking of blogging about the profile stacking problem [22:00:23] <blueness> SwifTy, anyhow there's a step-by-step example of reproducing the same error we had with multilb + selinux but, in my example, with libxml2 and python [22:00:43] <Zorry> the stacking should support depend,before,after [22:01:15] <blueness> Zorry, i'm not 100% sure i know what you mean [22:01:30] <blueness> if you guys give me a clear idea of what might work, i can suggest patches to portage [22:02:51] <blueness> Zorry, my one level deep idea would mean we could explicitly state the stacking order without the depth re-introducing stacks we don't want [22:03:13] <Zorry> blueness: in the parent file you can define what stuff need to be after or before the inhrite or if it depend of some subprofile [22:04:09] <blueness> Zorry, you mean something like services in openrc? [22:04:18] <Zorry> yee [22:04:43] <blueness> Zorry, okay people understand that logic already [22:05:23] <blueness> Zorry, do you want to suggest it on the bug and I can try to hack something up for portage? [22:06:08] <Zorry> will think of something this weekend [22:06:17] <blueness> i can write code to do "before", "after", "depend" in python, that logic is easy, but i forsee two problems: [22:06:34] <blueness> 1) how do we go from the current parent file to the new syntax? [22:06:53] <blueness> 2) i don't know how to integrate stuff with portage easily, i need zac for that [22:07:00] <blueness> and zac is MIA [22:07:11] <Zorry> 1 bump of the 13 to 14? [22:07:25] <blueness> even my install.py -> install (compiled C) is easy but how do I integrate it [22:07:50] <blueness> Zorry, yeah but i think we will need some kind of tags so portage knows whether its reading the old style parent or new style [22:08:16] <Zorry> yee something [22:08:17] <blueness> this sounds like a long term project anyhow, so i'm sure we'll work that out in time [22:08:27] <blueness> so syntax like ... [22:08:41] <blueness> before { [22:08:48] <blueness> hardened/linux/amd64 [22:08:50] <blueness> } [22:08:56] <blueness> after { [22:09:06] <blueness> default/linux/amd64 [22:09:07] <blueness> } [22:09:12] <blueness> depends { [22:09:13] <Zorry> something like that [22:09:19] <blueness> targets/desktop/gnome [22:09:20] <blueness> } [22:09:23] <blueness> Zorry, i like it! [22:09:45] -*- blueness feels all warm and fuzzy inside working in a team that inspires! [22:09:52] <lejonet> Verbose, so that anyone could understand it :) I agree with blueness, I like it :) [22:10:14] <blueness> okay guys, pursue that avenue for next time! [22:10:27] <Zorry> next topic? [22:10:30] <blueness> in the mean time, i'll clean up the broken/deprecate stuff to clear out cruft [22:10:38] -*- lejonet hands blueness the broom [22:10:50] -*- blueness make lejonet do the sweepign! [22:11:00] <lejonet> blueness: haha, more than fair enough :P [22:11:40] <SwifTy> ok, next :) [22:11:43] <Zorry> 6.0 Doc's [22:12:14] <SwifTy> aha, well i noticed blueness doing some wikiwork - go blueness !! [22:12:37] <blueness> SwifTy, please! [22:12:46] <blueness> stop damagin my reputation, i don't do docs! [22:12:55] <lejonet> haha [22:13:16] <SwifTy> i haven't touched hardened docs lately though, been too busy with general wiki and handbook stuff [22:13:24] <SwifTy> harhar [22:13:58] <Zorry> next? [22:14:03] <SwifTy> yup [22:14:15] <Zorry> 7.0 Bugs [22:14:34] <blueness> none worth mentioning [22:15:14] <SwifTy> here either [22:15:17] <prometheanfire> non [22:15:25] <Zorry> webkit-gtk 2.0.4 have textrel on x86 and it is even on defult profile [22:15:41] <blueness> Zorry, yeah [22:16:13] <Zorry> will wait on 2.2 something to see if is still there [22:16:15] <blueness> webkit-gtk has done some crazy stuff with .rb templates that's causing issues in uclibc too [22:16:27] <blueness> Zorry, where are the textrels from, does it have asm? [22:16:34] <blueness> err ... is it from the asm? [22:17:20] <Zorry> haven't look that close where in the code it is [22:17:45] <Zorry> just what function have it [22:17:54] <Zorry> thw textrel [22:17:59] <Zorry> the* [22:18:32] <blueness> Zorry, okay, i might look since i just solved the isnan issue there [22:18:49] <Zorry> !bug 483610 [22:18:52] <willikins> Zorry: https://bugs.gentoo.org/483610 "net-libs/webkit-gtk-2.0.4 - .../work/webkitgtk-2.0.4/tmp-introspectR49_vm/.libs/WebKit2-3.0: error while loading shared libraries: .../work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so.0: cannot make segment writable for relocation: Permission denied"; Gentoo Linux, Hardened; CONF; email:hardened [22:19:13] <blueness> k [22:19:38] <Zorry> next? [22:19:44] <blueness> yeah next, nothing more to say there [22:20:05] <Zorry> 8.0 Media [22:20:27] <blueness> nothing [22:20:30] <blueness> from [22:20:30] <blueness> me [22:21:04] <SwifTy> nope [22:21:26] <Zorry> next [22:21:37] <Zorry> 9.0 Open floor [22:21:52] <blueness> nothing, must run [22:22:04] <Zorry> ty for the meeting
