[gentoo-hardened] Meeting 2014-02-27 20:00UTC and log from last meeting.

[Magnus Granberg <zorry@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

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

[-- Attachment #2: meeting-2014-01-23_20:00UTC.log --]
[-- Type: text/x-log, Size: 19908 bytes --]

[21:03:28] <Zorry> 1.0 Toolchain
[21:03:58] <Zorry> gcc 4.8.2-r1 have ssp as default on (-fstack-protetor)
[21:04:11] <Zorry> but is still masked and no keyword
[21:04:47] <Zorry> is up to toolchain to make a news item
[21:04:54] <Zorry> for the change
[21:05:05] <blueness> Zorry, what had to change in the patches?
[21:05:53] <Zorry> blueness: i use the debian/ubuntu ssp patch and some gentoo fix to make it work the toolchain.eclass 
[21:06:10] <blueness> Zorry, okay
[21:07:06] <Zorry> the piepatchst needed some update but is was most only some remove of -fno-stack-protector 
[21:07:15] <Zorry> it have moved to the gentoo patchset
[21:07:53] <Zorry> so up to toolchain to make it happen
[21:08:16] <blueness> Zorry, oaky and what changes are there with our hardened patchset, or there is no overlap?
[21:08:28] <Zorry> no overlap
[21:08:46] <klondik1> hi
[21:08:52] <blueness> k
[21:08:57] <klondik1> writing from a pub
[21:09:08] <klondik1> :-)
[21:09:13] <blueness> Zorry, i have some stuff for uclibc
[21:09:16] <Zorry> blueness: any uclibc
[21:09:18] <blueness> yeah
[21:09:19] <klondik1> hour the battery lives
[21:09:33] <blueness> uclibc upstream has not release in nearly 2 years
[21:09:40] <blueness> so there are a lot of backlog of fixes
[21:09:41] <PLM3> How do I delete PT_PAX field from some file ?
[21:10:09] <blueness> i ask vapier to push out a new patchset and 0.9.33.2-r8 fixes a lot of problems
[21:10:17] <SwifT> PLM3: not now, online/irc meeting
[21:10:20] <blueness> in particular, it fixes a race condition in pread/pwrite
[21:10:22] <Zorry> PLM3: can you wait after the meeting?
[21:10:33] <PLM3> yeah, sure
[21:10:48] <blueness> this race meant that pread/write wsa not thread safe and this broke git-1.8 ... which was very bad
[21:10:59] <blueness> so no all the uclibc stages under /experimental have the fix
[21:11:15] <blueness> there were some other important fixes like a fix in eventfd which broke glib
[21:11:44] <blueness> and anything uisng glib (eg a desktop system like xfce4) was very very slow and ate up 100% cpu time on at least one core
[21:11:59] <blueness> i used to manually patch but that's not being pushed out in 0.9.33.2-r8
[21:12:12] <blueness> so the state of thost stage3's is the best they've ever been before
[21:12:20] <blueness> also
[21:12:25] <blueness> i have soemthing for musl
[21:12:35] <blueness> musl is yet another libc, its even slimmer than uclibc
[21:12:57] <blueness> i've now got a working stage4 for amd64, but not hardened yet
[21:13:09] <blueness> however, there are lots of patches against our packages
[21:13:42] <blueness> you can see all the packages i had to hack-up here -> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=tree;h=7aa40c8cb8ea1d31d9608b754a1976ed63ad4723;hb=7aa40c8cb8ea1d31d9608b754a1976ed63ad4723
[21:13:45] <blueness> but
[21:13:51] <blueness> musl is extremely fast!
[21:14:00] <blueness> so its worth trying to integrate it
[21:14:06] <blueness> </end>
[21:14:09] <blueness> questions?
[21:14:30] <Zorry> nope
[21:14:31] <SwifT> sounds like fun
[21:14:38] <klondik1> blueness we are not ricers :-P
[21:14:43] <Zorry> next then ?
[21:14:59] <klondik1> no
[21:15:08] <blueness> yes next
[21:15:15] <klondik1> Just have a small thing to say
[21:15:44] <klondik1> I think I have figured how to do profiles in llvm
[21:15:55] <klondik1> using pluggable modules
[21:16:19] <blueness> klondik1, what are "profiles" in llvm?
[21:16:24] <blueness> are they like specs?
[21:16:37] <klondik1> need to deepen on it but hopefully I'll get it working on a month
[21:16:52] <klondik1> no they are a bit more complicated
[21:17:09] <klondik1> as they have to be done in code
[21:17:39] <klondik1> then loaded as a pluggable module
[21:18:04] <klondik1> I probably can get something better hacked in though
[21:18:19] <blueness> klondik1, can they be used to add canaries and pie?
[21:18:31] <klondik1> I think so
[21:18:42] <blueness> how is linking done in llvm?
[21:18:56] <blueness> if we can also get relro and bind_now we have hardened llvm
[21:18:59] <klondik1> clang does all
[21:19:08] <blueness> klondik1, k
[21:19:20] <klondik1> I think I can pass the parameters to ld
[21:19:29] <klondik1> need to deepen on it
[21:19:39] <blueness> k
[21:19:40] <Zorry> relro is default on binutils
[21:19:58] <klondik1> we can also get the code reordering passes too
[21:20:29] <klondik1> (that's the cool part of my thesis which I presented today)
[21:20:32] <blueness> Zorry, but clang doesn't use binutil's ld
[21:20:55] <klondik1> blueness I think they do
[21:20:55] <Zorry> aha
[21:20:56] <blueness> klondik1, yeah solar pointed that out to me with gcc-3 hardeneing
[21:21:12] <blueness> klondik1, wait so clang needs binutil's ld?
[21:21:24] <klondik1> or gold
[21:21:37] <blueness> oh okay, sorry Zorry i was wrong i guess
[21:21:39] <klondik1> clang is like gcc
[21:22:14] <klondik1> driver and front-end
[21:23:05] <klondik1> I can elaborate on that later
[21:23:18] <klondik1> (hard to write with my phone)
[21:23:26] <klondik1> next?
[21:23:33] <Zorry> next then ?
[21:23:35] <Zorry> 2.0 Kernel Grsec/PaX 
[21:24:02] <prometheanfire> should we summarize the pax fun we had a month ago?
[21:24:07] <blueness> k
[21:24:26] <klondik1> pax fun?
[21:24:29] <blueness> Zorry, nothing new, there wsa that issue with PT/XT pax in the 3.12 kernels for a while
[21:24:49] <blueness> the idea is that if you have *both* pt and xt pax markings, they must be identical otherwise you default
[21:25:03] <blueness> some people had both setting in the kernel
[21:25:20] <blueness> we should problably choose one or the other in the long run
[21:25:26] <blueness> so that people don't hit this problem
[21:25:35] -*- prometheanfire had that, now is xtpax only
[21:26:00] <blueness> i think spender reverted anyhow, and i personally didn'thit it because i use xtpax only
[21:26:15] <klondik1> blueness that's a doc prob
[21:26:21] <prometheanfire> it is a doc problem
[21:26:22] <blueness> klondik1, probably
[21:26:27] <prometheanfire> are images being made xtonly now?
[21:26:31] <blueness> we need to emphasize it there
[21:26:41] <blueness> prometheanfire, which images?
[21:26:45] <prometheanfire> stage3
[21:26:56] <blueness> no
[21:27:11] <blueness> let me explain ... it doesn't matter if you have pt and xt pax markings on your userland
[21:27:17] <blueness> its the kernel setting
[21:27:19] <prometheanfire> it also needs to be doc'd in the kernel
[21:27:22] <blueness> either pick xt or pt but not both
[21:27:41] <blueness> if you pick xt in the kernel, and your userland has both, the kernel will just ignore the pt pax
[21:27:43] <klondik1> blueness it matters
[21:27:54] <blueness> klondik1, only if you pikc *both* in the kernel
[21:28:12] <klondik1> and Sunderland
[21:28:21] <klondik1> userland
[21:28:31] <klondik1> mobile bad
[21:28:44] <blueness> prometheanfire, anyhow until the stages are made with tar --xattr there are no xattr markings in the stage3s
[21:29:05] <blueness> but those changes are in ~arch as soon as tar etc go stable portage will do both markings
[21:29:09] <prometheanfire> ok
[21:29:15] <klondik1> if you have xattr and delete pt flags it works
[21:29:44] <blueness> klondik1, you can't "delete" the pt pax falgs really, the elf program header is always there, it just has all 0's in it
[21:29:47] <prometheanfire> which brings us to PLM3's question :P
[21:30:00] <blueness> you *can* delete the xt pax flags by just killing user.pax.flags xattr name filed
[21:30:02] <blueness> filed
[21:30:04] <blueness> err!
[21:30:06] <blueness> field
[21:30:23] <blueness> make sense?
[21:30:28] <prometheanfire> yes
[21:30:40] <blueness> one more thing for grsec/pax
[21:30:50] <blueness> (and then i must feed my dog)
[21:31:00] <blueness> the c wrapper for install is like 99.9% done
[21:31:15] <blueness> let me get the bug
[21:31:27] <SwifT> no, fix the 0.1%
[21:31:29] <SwifT> :p
[21:31:40] <blueness> bug #465000
[21:31:42] <willikins> blueness: https://bugs.gentoo.org/465000 "xattr pax-marking in src_compile() fails"; Gentoo Linux, Hardened; CONF; nikoli:hardened
[21:31:47] <klondik1> I can duo the rest if needed
[21:31:54] <blueness> SwifT, vapier and i went back and forth on style and a couple of fixes
[21:32:20] <blueness> look at -> https://bugs.gentoo.org/show_bug.cgi?id=465000#c42
[21:32:30] <blueness> comment #42 has the speedup
[21:32:50] <blueness> 2 mins for the c wrapper, 30 mins for the python wrapper for moodle
[21:32:59] <klondik1> klondike see this
[21:33:00] <blueness> badabing!
[21:33:14] <blueness> so please try it out
[21:33:14] <klondik1> now I get it on my laptop
[21:33:17] <SwifT> that's... noticeable ;)
[21:33:33] <Zorry> +1
[21:33:40] <blueness> SwifT, it was kinda obvoius immediately after zmedico added it
[21:34:03] <blueness> there is no way of persistantly keeping python alive for the thousand or so files to be installed for moodle
[21:34:15] <blueness> starting/stoping python 1000 times is crazy
[21:34:22] <blueness> i don't know why i was so implementationally stupid
[21:34:25] <blueness> but
[21:34:34] <blueness> maintaining a python wrapper is much easier than C
[21:34:57] <blueness> in C you have to fork code and exit the parent with the right signals and error code etc
[21:35:13] <blueness> luckily we documented it all in that bug so someone else can figure out why i did what i did
[21:35:27] <blueness> otherwise it would be hard to make sense of in the future
[21:35:39] <blueness> you know, in case i get hit by a bus or klondik1 decides to kill me :)
[21:35:47] <blueness> and now i must feed my dog
[21:35:48] <Arfrever> (Also document it in code using extensive comments :) .)
[21:35:50] <blueness> any questons
[21:35:54] <blueness> Arfrever, i tried
[21:36:08] <blueness> but comments in code don't always reveal design considerations
[21:36:10] <klondik1> no plans to kill you blueness
[21:36:12] <Zorry> blueness: will it be in elfix or portage the C file?
[21:36:18] <Zorry> the bin*
[21:36:31] <blueness> Zorry, i've pinged dol-sen to see about getting it integrated with portage
[21:36:37] <Zorry> okay
[21:36:39] <blueness> i don't know how to do that, but they do
[21:36:57] <blueness> zmedico is on devaway for who knows how long
[21:37:02] <blueness> so i guess its dol-sen
[21:37:16] <Arfrever> blueness: You can send patch for Portage's Makefile.
[21:38:01] <blueness> Arfrever, yeah but i don't know whether to invoke it using the shell script with the env variables set the way zmedico was invoking install.py
[21:38:15] <blueness> he had something wierd
[21:38:23] <prometheanfire> ok, I have to go now
[21:38:29] <blueness> the path to install lead to ..ebuild-helpers/install
[21:38:32] <klondik1> see y'all
[21:38:44] <blueness> and then that set up some env variables which in turn called install.py
[21:38:49] <prometheanfire> snowpocalypse is hitting san antonio, it's gonna get down to freezing... (normally in the 60s)
[21:38:53] <Arfrever> blueness: These variables are needed for Python.
[21:39:03] <blueness> Arfrever, but not for C?
[21:39:17] <blueness> so just repalce the shell script with the compiled c code?
[21:39:23] <Arfrever> blueness: No.
[21:39:39] <blueness> Arfrever, can you produce the Makefile patch then?
[21:39:50] <blueness> (sorry but my dog insists i feed him NOW)
[21:39:53] <blueness> brb
[21:40:07] <Zorry> okay next then ?
[21:40:09] <blueness> he's sitting here crying
[21:40:18] <klondik1> Oki
[21:40:18] <blueness> Zorry, yes, Arfrever and i will work this out later
[21:40:29] <Zorry> 3.0 Selinux
[21:40:36] <blueness> but i'll push to have the wrapper out asap
[21:40:37] <Arfrever> blueness: bin/ebuild-helpers/xattr/install should have:
[21:40:37] <Arfrever> if ${C_wrapper_exists}; then
[21:40:37] <Arfrever>   ${C_wrapper}
[21:40:37] <Arfrever> else
[21:40:37] <Arfrever>   ${current_code_for_Python_wrapper}
[21:40:37] <Arfrever> fi
[21:40:55] <SwifT> the rev 4 selinux policies are now stabilized (jan 14)
[21:41:07] <klondik1> I'm halfway through swift book
[21:41:19] <SwifT> i also stabilized the new selinux userspace on jan 20th, so our stable tree is up to par with upstream again
[21:41:53] <SwifT> for fcron, I submitted a patch upstreazm as one of our users got hit with its selinux implementation, but no reply there as of yet
[21:42:20] <SwifT> and finally, I removed the xfs instructions in the gentoo selinux handbook (inode count increase) as that's no longer needed - the default value is now big enough
[21:42:46] <klondik1> swift what's the fcron bug?
[21:42:59] <SwifT> upstream selinux is quite busy lately (with integration with linux kernel as well as userspace) so I expect some larger changes in the near future... policy-wise, things are rther silent due to dgrift's absense
[21:43:18] <SwifT> klondik1: it is trying to find the default context passing on the linux account name, rather than the selinux user name for that linux account
[21:43:34] <SwifT> which also triggered my blog post on how to write proper selinux apps ;)
[21:43:50] <klondik1> I see
[21:44:06] <SwifT> that's about it for selinux frmo my part - as you can see from devaway, i'm still in the "maintenance only" mode :(
[21:44:16] <SwifT> need a few more months to get back on my eet
[21:44:18] <SwifT> feet
[21:44:48] <Zorry> next?
[21:44:51] <SwifT> yup
[21:44:55] <Zorry> 4.0 System Integrity
[21:45:21] <SwifT> for SI I made a few moer updates on our hardening benchmark (which is going to replace the gentoo security guide), but nothing major
[21:45:42] <SwifT> I might get some unexpected help from my employer for that in the near future though
[21:46:00] <SwifT> they're also going to look into SCAP so I might have some time devotion on it for us ;)
[21:46:09] <Zorry> :)
[21:46:49] <SwifT> that's it for system integrity
[21:46:53] <blueness> back
[21:47:00] <Zorry> next then?
[21:47:03] <SwifT> yup
[21:47:13] <Zorry> 5.0 Profiles
[21:47:33] <blueness> yuck
[21:47:36] -*- blueness runs
[21:47:39] <Zorry> haven't done any thing on the new things
[21:47:47] <blueness> me neither
[21:47:58] <SwifT> either blueness is tired of profiles, or his dog chewed on his toe
[21:48:01] <klondik1> Zero_Chaos
[21:48:06] <blueness> i was going to write a blog post on the issue
[21:48:10] <SwifT> =)
[21:48:13] <blueness> SwifT, and he *is* doing that
[21:48:36] <klondik1> want there a desktop profile he was working on?
[21:48:38] <blueness> wierd coincidence, are you sure you don't work for the NSA and are watching me right now
[21:48:58] <SwifT> I'm not at liberty to deny or confirm that
[21:49:05] <blueness> klondik1, Zorry had a good idea of changing hte parent file so that it worked like openrc' init.d depends
[21:49:17] <blueness> so a profile could say something like ...
[21:49:20] <SwifT> but stop poking your finger in your nose
[21:49:25] <blueness> after prof1 prof2 prof3
[21:49:34] <blueness> before prof4 prof5 prof6
[21:49:42] <blueness> and portage would have to sort out the stacking
[21:49:43] <klondik1> :-)
[21:49:51] <klondik1> cool
[21:49:55] <blueness> so you'd go to the profile
[21:50:00] <blueness> read the parent file
[21:50:10] <blueness> stack according to that before/afters
[21:50:11] <blueness> then
[21:50:14] <klondik1> waiting for the conflicts :-P
[21:50:22] <blueness> go to those's profiles parent files
[21:50:29] <blueness> and expand them with before/afters
[21:50:43] <blueness> and then throw exceptions at conflicts
[21:50:44] <klondik1> I have the algorithm for it I think
[21:51:03] <blueness> klondik1, yeah the algo is pretty straight forward, maybe even just binary tree insert
[21:51:03] <klondik1> I used a similar one for instruction reordering
[21:51:42] <klondik1> :-)
[21:51:58] <klondik1> next then?
[21:52:00] <blueness> klondik1, if you could code it up in python for *just* parent files, we could attach that to a bug report and see if we can get the council to approve it
[21:52:05] <blueness> for some future EAPI
[21:52:14] <blueness> ie a poc
[21:52:19] <klondik1> I can python it if I have time yes
[21:52:29] <klondik1> klondike see that
[21:52:48] <blueness> klondik1, i can do it too, do you have your algo written up becuase its just vague in my mind now
[21:53:01] <klondik1> yes I do
[21:53:05] <blueness> i'm sure i can nail it but if you have an instruction reordering algo, that sounds very close
[21:53:09] <klondik1> part of my thesis
[21:53:24] <blueness> klondik1, is it binary tree insert-ish or like some kind of bubble sort?
[21:53:46] <klondik1> better
[21:53:52] <blueness> its slice bread!
[21:53:54] <klondik1> Will explain later
[21:53:59] <blueness> klondik1, okay let's talk alater
[21:54:06] <blueness> next!
[21:54:08] <Zorry> okay next ?
[21:54:16] <SwifT> next
[21:54:18] <klondik1> orc look for randins in the report
[21:54:35] <Zorry> 6. 0 Docs
[21:54:46] <Zorry> anything ?
[21:54:56] <klondik1> no
[21:54:59] <SwifT> nah, mentioned it in the selinux part already
[21:55:12] <Zorry> next then
[21:55:16] <blueness> what are docs?
[21:55:19] -*- blueness runs again
[21:55:20] <klondik1> having time now
[21:55:31] <klondik1> something to be done?
[21:55:34] <SwifT> sounds like bugs bunny
[21:55:42] <klondik1> add in higher priority?
[21:55:43] <blueness> klondik1, just the fix for the pt/xt pax thingy above
[21:55:56] <blueness> SwifT, that's "whats up docs"
[21:55:57] <SwifT> Zorry: yes, next before we collapse ;)
[21:56:00] <Zorry> 7.0 Bugs
[21:56:05] <klondik1> klondike do it
[21:56:24] <blueness> Zorry, nothing really
[21:56:28] <Zorry> okay
[21:56:35] <klondik1> nope
[21:56:40] <klondik1> oh wait
[21:56:55] <klondik1> a user has a strange problem
[21:56:59] <klondik1> idc
[21:57:21] <klondik1> udev was not on the not run level
[21:57:30] <klondik1> so the system was broken
[21:57:48] <klondik1> still not sure if he messed up or the stages are broken
[21:58:02] <PLM3> current stage3 doesn't have udev in startup
[21:58:05] <Zorry> the stage i think
[21:58:11] <PLM3> at least for hardened stages
[21:58:13] <Zorry> jmbsvicetto: ^^
[21:58:22] <klondik1> stage id's broken then
[21:58:52] <PLM3> oh wait... new stage3 that I haven't checked yet
[21:59:04] <PLM3> I was talking about last week stage3
[21:59:17] <klondik1> klondike ask the user to report it
[22:00:11] <Zorry> next?
[22:00:14] <SwifT> yup
[22:00:16] <klondik1> yes
[22:00:20] <Zorry> 8.0 Media
[22:00:25] <klondik1> me
[22:00:44] <klondik1> no tweets sorry
[22:00:50] <klondik1> about fosdem
[22:01:13] <klondik1> we can request a room for a bof on hardening
[22:01:40] <klondik1> same for Gentoo bof
[22:02:28] <klondik1> I also have more time these days so if anybody wants me to apply as  speaker somewhere tell me
[22:02:35] <SwifT> I think one on hardening isn't really needed - for gentoo in general, that might be interesting, but that should be discussed on -dev or -core
[22:03:05] <klondik1> swift will mail details to core
[22:03:08] <blueness> klondik1, any talks?
[22:03:21] <klondik1> no
[22:03:21] <Nikoli> how can i find all files with user.pax.flags?
[22:03:28] <klondik1> didn't get reply :-(
[22:03:48] <klondik1> late submissions are bad
[22:04:35] <klondik1> but I can arrange something in the hacker space
[22:04:45] <klondik1> as dev meeting or so
[22:04:48] <klondik1> g
[22:05:07] <klondik1> goteborg have space
[22:05:25] <klondik1> that's it from me
[22:05:45] <Zorry> SwifT:  was you going ?
[22:06:14] <klondik1> he is a done throw away
[22:06:16] <SwifT> Zorry: yes, but might not be able to make it fridays - I arrive in belgium friday evening
[22:06:22] <Zorry> okay
[22:06:52] <SwifT> the project in ireland might be done sooner, but I only know that thursday :p
[22:06:59] <Zorry> okay
[22:07:12] <SwifT> <Leon> Stop saying okay, okay?
[22:07:14] <SwifT> ;)
[22:07:28] <klondik1> Lejonet ping
[22:07:37] <Zorry> anything else?
[22:07:44] <klondik1> shall we look for a hotel
[22:07:58] <Zorry> meeting done and ty all