Meeting log 2013-09-26 20:00UTC

[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