[gentoo-hardened] Meeting log from 2013-05-16 20:00UTC

[gentoo-hardened] Meeting log from 2013-05-16 20:00UTC

[Magnus Granberg]

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

Hi
Meeting log from the last meeting.
/Magnus

[-- Attachment #2: meeting-2013-05-16:20:00UTC.log --]
[-- Type: text/x-log, Size: 13232 bytes --]

[22:03:57] <Zorry> 1.0 Toolchain
[22:04:24] <Zorry> gcc 4.8.1 will be out sone
[22:04:54] <Zorry> haven't done any thing with it from the last meeting
[22:05:21] <Zorry> some not much from me
[22:05:29] <Zorry> blueness:  do you have any thing?
[22:05:53] <blueness> just that i'm still maintaining the uclibc hardened stuff
[22:05:54] <pipacs> does 4.8.1 fix the plugin header install problem?
[22:06:04] <blueness> most of that is automated now through catalyst
[22:06:08] <blueness> and it just runs
[22:06:27] <solar> oh hi pipacs ltns
[22:06:36] <Zorry> pipacs: haven't seen any respons in the upstream bug
[22:06:44] <blueness> i've been hitting a lot of multilib bugs with uclibc, but they are not hardened specific
[22:06:50] <blueness> other than that nothing much more
[22:07:04] <Zorry> pipacs: patch is pasted on the gcc-patch ml and on the bug
[22:07:20] <pipacs> yeah i know but didn't see any comments on the bug since
[22:07:28] <pipacs> i thought they just fixed it since it's trivial
[22:07:40] <pipacs> will gentoo include the fix at least?
[22:07:44] <solar> blueness: you know SpanKY wrote the amd64 support for uclibc. I doubt he was trying to make it multilib aware
[22:07:49] <pipacs> 'cos it's a deal breaker for the pax plugins
[22:08:29] <Zorry> yep and some more gcc-plugin did depend on it
[22:08:42] <blueness> solar, no no that's not what i mean
[22:08:52] <blueness> uclibc is *not* multilib aware
[22:09:04] <Zorry> any one else?
[22:09:13] <blueness> so as a result a lot of packages that assume certain false things about multilib fails
[22:09:35] <SwifT> Zorry: so the (trivial) fix for the plugin header install is available in gentoo's releaes?
[22:09:36] <blueness> eg. audio-jack-kit always installs in /usr/lib64 when it should install in /usr/lib
[22:09:42] <blueness> solar, ^^
[22:10:01] <Zorry> SwifT: the fix is included in the gentoo gcc patchset
[22:10:06] <SwifT> Zorry: k
[22:10:18] <blueness> i'm done
[22:10:46] <Zorry> next then?
[22:10:55] <blueness> yes
[22:11:10] <Zorry> 2.0 Kernel and Grsec/PaX
[22:11:21] <blueness> okay
[22:11:38] <blueness> first about the xattr_pax migration, i've been too busy the past month to finish that
[22:12:21] <blueness> what remains to be done is 1) xattr copying in install for packages that do pax markings before src_install() and 2) xattr user.pax namespace patch for gentoo-soruces
[22:12:52] <blueness> this will silence errors for non-hardened users and fix the loss of xattr markings for those packages that do pax-mark before install
[22:12:59] <blueness> i know what to do, i just have not had the time to do it
[22:13:09] <blueness> then document it and see what else might fail
[22:13:36] <blueness> finally, i will test on both hardened and vanilla systems if PAX_MARKINGS="XT" causes issues and if not, i will turn it back on again
[22:13:54] <blueness> any questions/concerns with that before moving to my next point?
[22:14:25] <Zorry> can we add a pax-mark bash script?
[22:14:48] <Zorry> so we can use that when stuff is hardcoded in compile
[22:14:51] <blueness> Zorry, to elfix?  sure but i'm still not sure how it would be used, you mean like an eblit?
[22:15:12] <blueness> so you can call on it during ebuild's test phase?
[22:15:15] <Zorry> blueness: call that insted of paxctl/paxctl-ng
[22:15:45] <blueness> Zorry, the reason i'm confused is because that's done in the eclass
[22:15:57] <blueness> so under what circumstances do you need a separate bash script?
[22:16:00] <Zorry> for now most ebuild that have hardcoded calls to paxctl
[22:16:14] <Zorry> java/mono ...
[22:16:14] <blueness> Zorry, they should not
[22:16:39] <solar> anybody know what provides mkinitrd these days?
[22:16:41] <blueness> okay so instead of ebuils directly calling paxctl you want the bash script called, i can do that
[22:17:09] <Zorry> blueness:  is not the ebuild that call it is the make script
[22:17:29] <blueness> oh i see
[22:17:47] <blueness> hmmm ... that's a bit harder, show me after a good example and i'll see what i can do
[22:17:51] <Zorry> java&mono need to pax mark it selve to compile the rest
[22:18:02] <blueness> sheesh
[22:18:04] <blueness> okay
[22:18:29] <Zorry> we can talk about afer the meeting
[22:18:58] <Zorry> blueness:  go on
[22:19:20] <blueness> Zorry, yes if you show me an ebuild where we have an issue i'll fix it and add the stuff to elfix
[22:19:30] <amade> blueness, bug 467238
[22:19:48] <blueness> okay ... next quick point about hardened-sources and what versions are stabilized
[22:20:18] <blueness> so there was a secrurity issue with socks_diag code, and i had to rapid stabilize the versions you see in the topic
[22:20:39] <blueness> but now Azoff tells me he's having issues with the nfsd code and that 3.2.44 (and that set) fix it
[22:20:59] <blueness> so i will need to stabilize another round  ... hopefully there are no issues with that
[22:21:09] <blueness> but with the kernel, there is always a bug somewhere :(
[22:21:22] <blueness> just to let people know that in the next few days i'll be doing that
[22:21:33] <blueness> 0kay i'm done with kernel & grsec/pax
[22:21:55] <Zorry> pipacs:  any thing ?
[22:22:13] <Zorry> else next
[22:22:25] <Zorry> 3.0 Selinux
[22:22:43] <Zorry> SwifT: 
[22:23:03] <SwifT> more recent policycoreutils packages now contain a command "selocal" that allows users to simply enhance the local policy, without them needing to create their own modules to manage
[22:23:20] <SwifT> the script is a simple wrapper on top of the commands to do so, but might help, especially in resolving bugs
[22:23:41] <SwifT> I can just ask a user to "selocal -a <some selinux statement> -c "bug 12345" -Lb" and the statement is activated
[22:24:15] <SwifT> setools also had an old bug related to swig-1
[22:24:27] <SwifT> so i'm happy to say swig-1 is now slotted and setools uses the slotted version
[22:24:33] <SwifT> no more dependency breakage (hopefully)
[22:24:36] <Zorry> :)
[22:25:00] <SwifT> end of april, new userland utilities were released as well as new policy set; both are in the tree already, ~arch'ed
[22:25:31] <SwifT> the userland utilities had some stupid bugs in them, i've sent the paches upstream but there's not that much movement on it yet (but ok, it's only been a few weeks)
[22:25:49] <SwifT> i was also quite stupid to test the new userspace on a vm... that didn't have the new userspace
[22:26:04] <SwifT> but the versions in the tree now should work out fine
[22:26:34] <SwifT> finally, the policy ebuilds have been enhanced with epatch_user so that users (feandil and/or amade were asking for it) can do quick patching/testing as well
[22:26:48] <SwifT> that's it for selinux from me
[22:27:14] <Zorry> any one else?
[22:27:23] <blueness> i have a question
[22:27:41] <blueness> SwifT, now that tar has xattr support, it should be possible to build a stage3-...-selinux
[22:27:51] <blueness> have you looked into that?
[22:28:04] <SwifT> you'd think right? jmbsvicetto looked into that, but its a hornets nest
[22:28:06] <blueness> it could be added as a hook at the end of the stage3 catalyst code
[22:28:21] <blueness> SwifT, can you give me the jist of it?
[22:28:31] <blueness> ie why its a hornets nest?
[22:28:55] <SwifT> the problem is that the file context setting during chroots doesn't work out well, and that selinux-aware apps are failing to find proper feedback from the selinux security server
[22:28:55] <blueness> it would seem all you have to do is automate the installation of selinux as per the selinux-handbook
[22:29:32] <SwifT> i think jmbsvicetto first needed to get a seed that already was selinux-enabled, but i'm not sure if he got through with it
[22:29:53] <SwifT> building selinux stages is still on the horizon though, i'm just not sure when
[22:30:34] <blueness> SwifT, would this work for you ... write a bash script which takes a stage3, unpacks it, selinux-ifies it, repacks it
[22:30:55] <blueness> so its not exactly the flow one has with catalyst, but an add-on at the end
[22:31:12] <blueness> it might "dirty" the stage3, but it might do the trick
[22:31:57] <SwifT> I tried just adding all the files of the packages that should be in a stage3 in a tarball from my system (which is SELinux-enabled), but that then failed because of the context issue... perhaps that might now work with xattr-enabled tar
[22:32:27] <SwifT> selinux-ifying still means rebuilding a lot of code, so I think copying it for a seed is faster
[22:32:54] <blueness> SwifT, i know it means rebuidling but it has a better chance of working
[22:33:03] <SwifT> but if someone has a good tutorial on how to use catalyst to create the proper stages... I went with a script that vapier (i think) has online
[22:33:05] <blueness> okay let's move on ....
[22:33:15] <Zorry> 4.0 System Integrity
[22:33:50] <Zorry> SwifT: 
[22:34:06] <SwifT> not much to say... the patches accepted by the ima team haven't made it to the main kernel yet, so we currently only support "default" IMA/EVM setups
[22:34:23] <SwifT> as long as those patches aren't in, we can't use custom policies and need to run with EVM=fix mode
[22:34:41] <SwifT> but that's just a matter of time, there was noone disagreeing with the patch
[22:34:59] <jmbsvicetto> SwifT / blueness: I did create a stage3 seed
[22:35:20] <SwifT> that's all for integrity for now
[22:35:34] <SwifT> (given a userspace release of selinux and new policies, that was the major work the last month :p
[22:35:38] <jmbsvicetto> http://www.jmbsvicetto.name/stage3-hardened-selinux-20130420.tar.xz
[22:36:08] <jmbsvicetto> SwifT / blueness: we can talk later, but stage1 was failing to build
[22:36:09] <Zorry> next
[22:36:32] <Zorry> 5.0 Profiles
[22:36:48] <blueness> jmbsvicetto, k later
[22:36:59] <blueness> Zorry, shall i mention the problem with no-multi?
[22:37:06] <Zorry> have fixed two no-multilib bugs
[22:37:14] <blueness> so there is an issue with hardened/amd64/no-multilib
[22:37:15] <Zorry> in the profile
[22:37:43] <Zorry> the 1 one was a qa and that is fixed
[22:38:34] <blueness> because of the awkward profile stacking, hardened/amd64/nomutlilib does not inherit from arch/amd64/no-multilib
[22:38:40] <Zorry> 2 is a mess we miss to include on profile but with that included we get a lot of dups profiles in the profiles
[22:38:50] <blueness> as a result we are missig some maskings
[22:39:00] <Zorry> so i mirror the needed changes
[22:39:18] <blueness> i think so too, mirror those maskings
[22:39:35] <blueness> i was going to do that after the meeting if everyone is in agreement with the mirroring
[22:39:37] <Zorry> will wait for the real fix in the real no-multilib profile
[22:39:42] <blueness> because changing the stack is uncontrolable
[22:39:57] <blueness> Zorry, so you think wait?
[22:40:14] <Zorry> to include the profile
[22:40:38] <Zorry> i mirror the change now
[22:41:04] <blueness> Zorry, oh you did it already?
[22:41:11] <Zorry> yep
[22:41:14] <blueness> okay
[22:41:19] <blueness> did you test?
[22:41:34] <Zorry> nope but is was trevel changes
[22:41:36] <blueness> i guess i'll find out in a bit since all my severs are amd64/no-multilib :)
[22:41:45] <blueness> yeah they were just maskings
[22:41:50] <blueness> for the emu* stuff
[22:41:54] <Zorry> yep
[22:42:13] <Zorry> and some stuff  for the new emu* stuff
[22:42:15] <blueness> Zorry, actually i did mirroring too for uclibc
[22:42:35] <blueness> it was easier then trying to control the stack
[22:43:01] <Zorry> yep
[22:43:02] <blueness> Zorry, when did you mirror because i'm not seeing it yet?  did you do it todya?
[22:43:33] <Zorry> 1h ago type
[22:43:44] <blueness> ah okay that explains it
[22:44:25] <Zorry> and i have added a ChangeLog in the hardened profile so we don't need to do it on the main changelog
[22:44:28] <blueness> also i will remove the experimental hardened/linux/13.0 directory since all hardened profiles are now 13.0
[22:44:34] <blueness> that's just clean up
[22:44:42] <blueness> i wanted to wait a month after deprecating
[22:45:00] <blueness> no more from me on profiles
[22:45:12] <Zorry> any one else?
[22:45:42] <SwifT> noep
[22:45:52] <Zorry> next
[22:45:56] <Zorry> 6.0 Docs
[22:46:36] <Zorry> SwifT: klondike any thing?
[22:46:49] <SwifT> two things; the updates in selinux have been added to the selinux handbook as well
[22:47:07] <SwifT> and i'm slowly but surely writing a set of "tutorials" for users who want to learn selinux on the gentoo wiki
[22:47:20] <blueness> the Grsecruity 2.0 doc is way out of date, i should probably fix that
[22:47:23] <SwifT> https://wiki.gentoo.org/wiki/SELinux/Tutorials for those interested
[22:48:39] <Zorry> next ?
[22:48:49] <Zorry> 7.0 Bugs
[22:49:09] <Zorry> any one?
[22:49:25] <SwifT> nothing major from me
[22:50:32] <Zorry> on the libffi thing i still wait for upstream
[22:50:49] <Zorry> else i don't have any thing
[22:51:00] <Zorry> 8.0 Media
[22:51:06] <Zorry> klondike: ?
[22:51:33] <SwifT> he mentioned on twitter he'll be late... probably too late apparently
[22:51:43] <Zorry> looks that way
[22:51:54] <Zorry> next then?
[22:52:04] <Zorry> 9,0 Open floor
[22:52:22] <Zorry> any thing else meeting is done
[22:52:42] <Zorry> ty all for the meeting
[22:52:50] <SwifT> ty all for the work!