Sorry for a late meeting log. /Magnus
[22:12:58] <Zorry> 1.0 Toolchain [22:13:04] <lejonet> :) [22:13:14] <Zorry> not mutch news there [22:13:33] <klondike> I do have news [22:13:46] <blueness> me neither, no extra work on hardened uclibc [22:13:56] <blueness> just maintaining [22:13:57] <Zorry> default gcc 4.8.X will most likly have ssp enable as default [22:14:22] <Zorry> gentoo default gcc 4.8.x [22:14:42] <SwifT> yes; saw the discussion on [email protected] about that; good news [22:15:05] <blueness> Zorry, will we drop hardened-nossp? [22:15:18] <blueness> or any changes to our specs? [22:15:50] <Zorry> yep but still toolchin need to discuss how to do it and it where it is now [22:16:17] <klondike> Wow, this is amazing [22:16:31] <klondike> It only took like 8 years :) [22:16:42] <klondike> I think we are still faster than Microsoft [22:16:46] <Zorry> blueness: i think we still will have the nossp thing [22:17:33] <blueness> okay i like that [22:17:35] <blueness> it gives choice [22:17:54] <Zorry> blueness: we enable the -all version and default will the lover ssp [22:18:54] <Zorry> thats all from me [22:19:09] <Zorry> klondike: what news ? [22:19:23] <klondike> I'm working on llvm for my Master's Thesis, hopefully I can revert that knowledge back to a hardened clang. [22:19:34] <lejonet> klondike: cool :D [22:19:50] <klondike> All I'm developing is going to be free software [22:20:02] <onox> BSD license? :) [22:20:05] <klondike> And some operations can be used to harden binaries in systems like Gentoo [22:20:12] <lejonet> I still need to finally decided what I should do with my bachelor thesis :/ [22:20:13] <klondike> onox: llvm compatible [22:20:23] <specing> That is a perfect chance to GPL infect the LLVM toolchain! [22:20:43] <klondike> No License wars with this I want people to use it! [22:20:44] <onox> lol :) [22:20:57] <specing> Im not starting any license wars [22:21:06] <specing> you all know GPL is the only license [22:21:08] <SwifT> Zorry: if we stay with -nossp, perhaps we can call it "-nofullssp" then? [22:21:13] <specing> one & only [22:21:28] <klondike> I will send you a private memo with the details to the hardened alias since most of this still is unpublished and untested :) [22:21:30] <SwifT> Zorry: or would you really go without any stack potection? [22:22:04] <Zorry> SwifT: without any ssp [22:22:07] <blueness> SwifT, its good to have that [22:22:22] <blueness> you may need to test without ssp [22:22:25] <klondike> For now that's all for me :) hopefully much more next month [22:22:27] <blueness> as a standard [22:22:41] <SwifT> ok [22:22:56] <onox> blueness: could you add back 3.10.x kernel? [22:23:20] <Zorry> any one else? [22:23:23] <Zorry> else next [22:23:24] <blueness> nope nothing else [22:23:32] <lejonet> next :) [22:23:42] <Zorry> 2.0 Kernel and Grsec/PaX [22:24:04] <blueness> only one major outstanding issue with pax [22:24:09] <blueness> well with xattr pax [22:24:30] <blueness> everything is in place, but the install.py wrapper for coreutils' install is very very slow [22:24:47] <blueness> i have not yet gotten together with zmedico to figure out what to do here [22:25:07] <prometheanfire> blueness: if you only have one outstanding issue, update bug 427888 :P [22:25:08] <blueness> but basically for builds which invoke many instances of install, the emerge process is very slow [22:25:08] <willikins> prometheanfire: https://bugs.gentoo.org/427888 "[TRACKER] Introduction of xattr based pax markings to Gentoo"; Gentoo Linux, Hardened; CONF; blueness:blueness [22:25:28] <blueness> prometheanfire, on major, the others are minor [22:25:38] <prometheanfire> ah, ok [22:25:51] <SwifT> oh, that's why I have USE="-doc" done because dohtml was extremely slow [22:26:12] <blueness> this one -> https://bugs.gentoo.org/show_bug.cgi?id=465000 [22:26:19] <Zorry> blueness: is it many ebuilds that need the install fix? [22:26:38] <onox> I used to use pkgcore a while ago, much faster than emerge [22:26:44] <blueness> there are quite a few yes [22:27:01] <blueness> i mean the other way would have been to call pax-mark in the ebuilds after install [22:27:09] <Zorry> was thingking way just mark it a secund time? [22:27:15] <blueness> or for those that need it in the test phase, wed'have to mark twice [22:27:23] <blueness> Zorry, yes that's possible too [22:27:40] <SwifT> is it the fact that it's python that gives the overhead? [22:27:44] <blueness> but that doesn't really preserve end-to-end xattrs [22:27:47] <Zorry> if is not that many that need the fix [22:27:49] <blueness> SwifT, yes [22:28:08] <blueness> Zorry, we may want this for other things too, like ACLs [22:28:35] <blueness> the best solution would be to replace install.py with a compiled version of install which we patch [22:29:12] <blueness> but i don't know how to do that and i haven't gotten anything back from zmedico [22:29:38] <blueness> Zorry, what do you think? drop install.py and just do the double pax-mark? [22:30:11] <klondike> blueness: in C? [22:30:13] <Zorry> but do the patched install need to check xattre on all files it install or only if it have one? [22:30:22] <blueness> klondike, yes in C [22:30:37] <SwifT> would it make sense to have the list of pax markings be stored in the profile rather than in the packages, and have portage assign the necessary markings through hooks? [22:30:38] <klondike> How many python lines? [22:30:53] <blueness> Zorry, it would just preserve whatever is there for the name spaces we specify [22:31:19] <blueness> SwifT, i believe the used to do something like that with chpax [22:31:25] <blueness> and EI_PAX markings [22:31:40] <blueness> there was an init script which read a config file and did the markings on each boot [22:31:47] <blueness> it was messy [22:32:08] <blueness> SwifT, also, some tests fail without the markings done before the test phase [22:32:15] <Dwokfur> I preserved the init script and the conf and still using it since pax-marking currently borked [22:32:30] <Dwokfur> It works well with paxctl-ng [22:32:38] <blueness> Dwokfur, interesting! [22:32:43] <SwifT> blueness: I meant to have portage do it - not openrc or so... so before src_test() is run, and after pkg_install() and so on [22:33:34] <blueness> i don't know how i'd write such a wrapper but maybe that's an idea [22:33:50] <blueness> maybe in the eclass [22:34:06] <blueness> add a pax_utils_src_test and pax_utils_pkg_install? [22:34:24] <Dwokfur> blueness: marking while emerging is definitely better compared to an openrc solution [22:34:38] <blueness> Dwokfur, agreed [22:34:57] <blueness> SwifT, do you have any implementation details in mind? [22:34:59] <SwifT> for instance - but that does mean you'll need to have a repository somewhere that tells it what the markings should be; knwoledge that's currently only available in the ebuilds themselves through some calls, not? [22:35:44] <SwifT> just thinking loud here, but perhaps have the ebuilds use a bash array with the markings they need, and then have the eclass functions do the markings when needed? [22:35:54] <Dwokfur> not that many markings are necessary on top of the default currently, IMHO [22:36:09] <blueness> SwifT, the bash array idea plus pax_utils_src_test and pax_utils_pkg_install might do it [22:36:19] <klondike> Dwokfur: try with new llvm 3D drivers [22:36:43] <blueness> it dissapoints me that we can't have end-to-end xattr support though [22:37:06] <blueness> i think i'll pursue the compiled install idea this month and revert to other solutions if it fails [22:37:21] <Zorry> ok [22:37:51] <klondike> blueness: how many python lines has the wrapper? [22:37:58] <blueness> i'll comment on bug #465000 [22:38:00] <willikins> blueness: https://bugs.gentoo.org/465000 "xattr pax-marking in src_compile() fails"; Gentoo Linux, Hardened; CONF; nikoli:hardened [22:38:14] <blueness> https://465000.bugs.gentoo.org/attachment.cgi?id=351600 [22:38:17] <blueness> klondike, ^^^ [22:39:44] <blueness> anyhow, nothing more from kernel pax/grsec [22:39:50] <blueness> shall we move on? [22:39:53] <Zorry> next then? [22:40:07] <Dwokfur> I forgot why XT marking is better than PT - maybe it's just me... [22:40:15] <Zorry> pipacs: do you have any thing? [22:40:15] <pipacs> skype ;) [22:40:25] <pipacs> not really [22:40:30] <klondike> I knew it! [22:40:41] <prometheanfire> pipacs: hithere [22:41:09] <Zorry> 3.0 Selinux [22:41:26] <quantumsummers|c> can I ask a question real fast? [22:41:37] <quantumsummers|c> kernel related? [22:41:48] <quantumsummers|c> or are we past that already [22:41:49] <SwifT> sure, fast [22:41:53] <SwifT> quickly [22:41:54] <SwifT> now [22:41:57] <SwifT> :p [22:42:00] <klondike> be SwifT quantumsummers|c [22:42:13] <Zorry> quantumsummers|c: go on [22:42:25] <quantumsummers|c> pipacs: I have a question for you (talked with spender about it a little). What do you think the chances are for lts 3.10 [22:42:40] <quantumsummers|c> mainly, I am interested in this for myself [22:42:46] <quantumsummers|c> but I suspect there are others too [22:43:12] <pipacs> it's been discussed already [22:43:13] <quantumsummers|c> I understand that grsec may not have the manpower/funding, so perhaps it is too much [22:43:20] <pipacs> we won't do 3.10, we moved to 3.11 in fact already [22:43:22] <prometheanfire> afaik, they lts what they get paid for, and they get paid for lts ubuntu (so not 3.10), I think that's right correct me if I'm wrong pipacs [22:43:30] <pipacs> and choose something next spring probably [22:43:37] <quantumsummers|c> ok then [22:43:46] <klondike> quantumsummers|c: you can sponsir spender [22:43:57] <quantumsummers|c> I have to sponsor myself [22:44:04] <SwifT> =) [22:44:11] <klondike> That was plural you :) [22:44:17] <SwifT> do, I can go on about SELinux now? ;) [22:44:21] <Zorry> yes [22:44:21] <quantumsummers|c> yes please [22:44:24] <quantumsummers|c> sorry, thanks [22:44:27] <SwifT> nothing big this month; I sent our libselinux patches to the selinux mailinglist again in the hope they get picked up (or updated); it's a third time (first time they thought about doing things differently, second time no feedback) [22:45:07] <SwifT> and I also today pushed out rev3 of the policies *with* the script how to release new versions in case I suddenly die :p [22:45:23] <prometheanfire> SwifT: I saw that upstream is picking up on commits [22:45:43] <SwifT> policies - yes; libraries/software - not that much [22:45:48] <prometheanfire> right [22:46:02] <SwifT> policy upstream has suddenly be violently active again after months of slow passing [22:46:23] <SwifT> r3 contains most of upstream up to yesterday [22:46:35] <SwifT> I still need to merge the changes of today in the tree but I don't see any biggies there [22:46:52] <SwifT> that's it for SELinux [22:47:54] <Zorry> 4.0 System Integrity [22:48:22] <SwifT> thanks to Montjoie (or montjoie[home]) we have a fairly good record of getting the latest openscap in our tree [22:48:31] <SwifT> openscap -> handling security content automation protocol stuff [22:48:54] <SwifT> I'm using openscap to test and develop hardening guides (which is part of the compliance/reporting part of system integrity) [22:49:17] <SwifT> next to SCAP, I also wrote a "using signed kernel modules" guide on the wiki [22:49:35] <SwifT> which, btw, is very easy to work with/use [22:49:44] <SwifT> https://wiki.gentoo.org/wiki/Signed_kernel_module_support for the interested [22:49:59] <SwifT> that's it for system integrity [22:50:01] <prometheanfire> SwifT: I'm interested in anything you can say with integration of integrety stuff into puppet/chef and the like [22:51:00] <SwifT> prometheanfire: nothing right now - puppet and scap content might be on the same level for some things, but I don't know if puppet supports SCAP content [22:51:14] <prometheanfire> SwifT: ok, done :D [22:51:41] <Zorry> next? [22:51:47] <SwifT> yes [22:51:50] <Zorry> 5.0 Profiles [22:52:44] <blueness> Zorry, the only change has been that you added eapi 5 to amd64 and x86 [22:52:47] <blueness> i have nothing new [22:52:59] <Zorry> have update the profile to need eapi 5 supported portage [22:53:20] <Zorry> on amd64 and x86 [22:53:34] <Zorry> it have with the new multilib stuff [22:54:15] <Zorry> any one else? [22:54:35] <SwifT> nope - aint that cool; I remember the days we had to discuss profile changes over and over again [22:54:38] <SwifT> :-) [22:54:58] <Zorry> 6.0 Docs [22:55:36] <Zorry> any new there? [22:55:55] <SwifT> I'm working on gentoo security baselines in the hardened-docs git repo [22:55:59] *** Mode #gentoo-hardened +v NeddySeagoon by ChanServ [22:56:00] <klondike> Not from me [22:56:04] <SwifT> its results are currently made available on http://dev.gentoo.org/~swift/docs/security_benchmarks/ [22:56:13] <SwifT> still a work in progress though [22:56:19] <prometheanfire> wiki stuff? [22:56:25] <prometheanfire> SwifT: can you open up http://dev.gentoo.org/~swift/docs/ ? [22:56:53] <SwifT> no [22:56:54] <SwifT> :p [22:57:07] <SwifT> about wiki, I moved most of our documents to the user-editable namespace [22:57:14] <klondike> Works here [22:57:25] <SwifT> it's the index to /docs/ that isn't open [22:57:27] <klondike> Good for me :) [22:57:54] <SwifT> prometheanfire: ~swift/docs isn't a nice place to look for my docs :p [22:58:22] <prometheanfire> well, it implies ALL your docs, which would be better then bookmarking multiple subpages [22:58:28] <prometheanfire> SwifT: book? [22:58:29] <SwifT> but i'm probably going to place a few index.xml in my public_html/ location [22:58:44] <SwifT> today I heard that it was available - I mailed the publisher for more details ;) [22:59:33] <prometheanfire> cool, done here [22:59:35] <SwifT> that's it for docs for now from me [22:59:36] <klondike> I still stand for my opinion [22:59:55] <prometheanfire> klondike: ? [23:00:12] <klondike> I will pirate it and pay SwifT a good beer [23:00:21] <prometheanfire> ic [23:00:25] <Zorry> next ? [23:00:26] <SwifT> you know, IRC is quite public... [23:00:27] <SwifT> :p [23:00:32] <SwifT> yes, next [23:00:34] <Zorry> 7.0 Bugs [23:01:11] <Zorry> any thing else next [23:01:11] <klondike> I haven't had time to work on the ffmpeg one [23:01:12] <prometheanfire> should we keep the vmware on hardened bugs open or should we add it to our docs and close the bugs? [23:01:33] <klondike> Not sure how is the one Zero_Chaos told me about going either [23:01:47] <blueness> prometheanfire, for a long time now, i've concentrated my effort on kvm for hardened both guest and host [23:02:06] <blueness> and its working fine, except there are the occasional bugs, like the one now for h-s-3.11.1 [23:02:08] <Zorry> prometheanfire: open i think else some one will make a new one [23:02:14] <prometheanfire> blueness: I know, I'm saying we should state that we DON'T support it at all (vmware/virtualbox) [23:02:24] <prometheanfire> Zorry: fair enough [23:02:25] <blueness> prometheanfire, say support is spotty [23:02:46] <blueness> and add that we do support kvm [23:02:53] <prometheanfire> I don't know of one instance of it working at all :P [23:02:57] <prometheanfire> but on [23:02:58] <prometheanfire> ok [23:04:01] <klondike> prometheanfire: go the cool way then [23:04:28] <klondike> Say we don't have time to support it and that any efforts on his side towards supports will be appreciated [23:04:37] <prometheanfire> oh ya, I won't be giving my talk at the openstack confrence :( [23:04:43] <SwifT> :( [23:04:47] <klondike> :( [23:04:56] <klondike> Not enough votes? [23:04:56] <prometheanfire> didn't expect much [23:04:58] <prometheanfire> ya [23:05:03] <klondike> Well [23:05:15] <klondike> This means I can make my vuln public :P [23:05:21] <prometheanfire> orly? [23:05:25] <klondike> Yeah [23:05:31] <Zorry> next ? [23:05:37] <prometheanfire> new CVE against openstack? won't that make you unique :P [23:05:39] <prometheanfire> next [23:05:55] <Zorry> 8.0 Media [23:06:18] <klondike> Oh that's a me [23:06:32] <klondike> blah blah blah twitter blah blah blah [23:06:43] <klondike> No talks in foresight yet [23:06:59] <klondike> And I won't be arranging the sec trackat fscons ENOTIME [23:06:59] <SwifT> oh it's twitter that's making my phone vibrate all this time :p [23:07:03] <klondike> xD [23:07:14] <Zorry> klondike: thinking to have any fosdem talk? [23:07:22] <klondike> Yes [23:07:37] <klondike> One called Zorry presents: gcc guts! [23:07:56] <klondike> I don't mind supporting you for that one :P [23:08:02] <lejonet> :P [23:08:03] <prometheanfire> I'm considering fosdem, but I may be working at another company and not have time [23:08:08] <klondike> And I may present my research on llvm there [23:08:15] <prometheanfire> blueness should go to fosdem [23:09:55] <Zorry> done ? [23:10:24] <prometheanfire> yes [23:10:26] <Zorry> 9.0 Open floor
