[gentoo-hardened] Meeting log

[gentoo-hardened] Meeting log

[Magnus Granberg]

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

Sorry
/Magnus

[-- Attachment #2: meeting-2011-08-24_20:00UTC.log --]
[-- Type: text/x-log, Size: 22112 bytes --]

[22:09:01] <Zorry> lets start then
[22:09:33] <Zorry> 1.0 Project lead
[22:10:33] <Zorry> we need to shose a project leader
[22:10:56] <Zorry> one year have past
[22:11:17] <prometheanfire> Zorry++
[22:11:28] <blueness> Zorry, do you want to continue doing it?
[22:11:30] <Zorry> do we have any then me selectet for it ?
[22:11:59] <SwifT> everyone that knows the gang knows no-one else can lead them :p
[22:12:40] <Zorry> so vouit for me then?
[22:12:50] <SwifT> Zorry++
[22:12:57] <blueness> vote for Zorry
[22:13:42] <Zorry> quantumsummers|a:  SwifT?
[22:14:09] <SwifT> yup, vote for Zorry too
[22:15:26] <Zorry> hmm quantumsummers|a
[22:15:39] <blueness> i think quantumsummers|a just faded out
[22:15:52] <SwifT> he wooshed away when he saw another openrc bug
[22:16:10] <Zorry> looks that way
[22:16:25] <blueness> it doesn't matter, the only peole that can vote are the team devs, so majority voted
[22:16:37] <Zorry> so it looks that i stay as the leat one more year then
[22:16:41] <blueness> congrats
[22:16:47] <SwifT> my condoleances
[22:16:56] <blueness> that too :)
[22:17:01] <Zorry> ty
[22:17:18] <Zorry> then next 
[22:17:45] <Zorry> 2.0 EI_PAX/PT_PAX changes
[22:17:50] <Zorry> blueness: ^^
[22:17:52] <blueness> yep
[22:18:12] <blueness> history: EI_PAX is the old way of marking binary, PT_PAX is the new way
[22:18:30] <blueness> EI_PAX "hijacks" a byte from the elf header which it shouldn't do, but it does
[22:18:36] <blueness> PT_PAX is the proper way of oding it
[22:18:57] <blueness> i was going to eliminate all EI_PAX from the kernel and elf binaries, but ...
[22:19:16] <blueness> there are some corner cases where it is impossible to mark binaries except via EI_PAX
[22:19:42] <blueness> prebuilt binaries where either 1) they are self checking, 2) there is no space to expand the program headers section
[22:19:44] <blueness> so
[22:20:22] <blueness> new plan is to "lock" the the EI_PAX and PT_PAX markings and make sure there is consistency between them on gentoo systems
[22:21:06] <blueness> so the "legacy" option will just lock with the PT_PAX option in the kernel and then all markings will mark both EI_PAX and PT_PAX identically so there are no inconsistencies
[22:21:32] <blueness> i don't think it will be possible (ever?) to completely remove EI_PAX because we will always have to deal with precompiled binaries
[22:21:43] <Zorry> +1
[22:21:47] <blueness> i'm going to write a mini explanation which I'll put online
[22:22:03] <prometheanfire> sounds good
[22:22:05] <blueness> any comments?
[22:22:21] <Zorry> do it :)
[22:22:24] <blueness> k
[22:22:30] <SwifT> what do you mean with "lock"?
[22:22:57] <blueness> the only problem would be in the far future, if byte 14 of the elf header is allocated to something else
[22:23:26] <blueness> SwifT, lock just means that the kernel will first look for PT_PAX program header and if it exists use those markings
[22:23:26] <SwifT> does this mean that the (new) toolchain will do both?
[22:23:41] <blueness> if it does not, then it will look to EI_PAX
[22:24:04] <blueness> on the userland side, we'll make sure that both EI_PAX and PT_PAX markings are always identical
[22:24:10] <blueness> if both fields exist
[22:24:20] <blueness> otherwise, only the EI_PAX will be marked
[22:24:41] <SwifT> will there be a possibility of disabling EI_PAX marking?
[22:24:50] <blueness> i should explain that you can *always* do EI_PAX markings because there is always a byte available in the elf header to use
[22:24:56] <SwifT> for those that do not want to do that (and are not using any of the corner cases)?
[22:25:05] <blueness> but you cannot always expand the elf program headers to include a PT_PAX field
[22:25:26] <blueness> 1) it *is* possible to eliminate EI_PAX completely, but then we would not have things like skype
[22:25:36] <Zorry> SwifT: most time it will dwfault to pt_pax mark
[22:25:52] <blueness> 2) i for those that want only PT_PAX, no problem if it finds it it is the default
[22:26:18] <SwifT> k
[22:26:31] <blueness> i don't want users to start enable only legacy and then marking PT_PAX since that would mess up
[22:27:21] <blueness> the *only* danger i see is if some new posix standard comes out changing something about elf headers
[22:27:34] <Zorry> yep
[22:27:35] <blueness> *and* the magic byte is then allocated to something else
[22:27:57] <blueness> that's why we wanted to get rid of it, its like stealing a database field for something it was never meant for
[22:28:11] <SwifT> ack
[22:28:12] <blueness> then later you want to use it for the original purpose and you're stuck
[22:28:39] <blueness> yeah so if one day that byte starts to mean something else, then we're stuck
[22:29:11] <blueness> so some decision has to be made about which path to follow.  it has been over 10 years and the reserved area has not been allocated to soemthing else, so ....
[22:29:14] <blueness> there you go
[22:29:43] <blueness> i'll email the list a link to my little mini "glep" when i've finished writing it
[22:30:00] <blueness> if there are no questions, i'm done
[22:30:06] <Zorry> okay
[22:30:40] <Zorry> next then
[22:31:04] <Zorry> 3.0 toolchain
[22:31:35] <Zorry> don't have any news here
[22:31:41] <Zorry> there*
[22:31:58] <Zorry> 4.6.1 and 4.5.3 looks working fine
[22:32:22] <SwifT> it's been a while that the autobuilds have produced a hardened stage for amd64 (multilib or not), is that toolchain related?
[22:32:22] <prometheanfire> what are the blockers?
[22:32:28] <Zorry> and haven't don any thing to the upstream patch for 4.7
[22:33:11] <Zorry> prometheanfire: it is up to the toolchain to disade when gcc 4.x gose stable
[22:33:26] <Zorry> SwifT: the problem is the stage build box
[22:33:38] <blueness> Zorry, there are some problems still with the hardened kernel compile with 4.5 and 4.6, but pipacs is looking into it and says the fix is done
[22:33:54] <Zorry> for it works fine for me and blueness, jmbsvicetto to build it
[22:34:07] <blueness> https://bugs.gentoo.org/show_bug.cgi?id=378731
[22:34:16] <blueness> on x86
[22:34:33] <Zorry> yep is most a kenel prob
[22:34:59] <blueness> it is/will be fixed, it is a hardened-sources problem, i just mention it
[22:36:09] <Zorry> else i don't have any thing more to say
[22:36:17] <blueness> k
[22:36:32] <Zorry> to busy with the tinderbox stuff :(
[22:36:49] <Zorry> so next then
[22:36:57] <Zorry> 4.0 Kernel
[22:37:21] <prometheanfire> 3.0.3 from upstream is out, pax has more fixes that need in
[22:37:36] <blueness> we have that one bug, but like i said, it will be cleaned up
[22:37:51] <blueness> 2.6.32 continues to be supported by uptream
[22:38:18] <blueness> we have on stable 2.6.39, there may not be another stable 2.6.39 becuase of that bug above
[22:38:44] <blueness> upstream has released a 3.0.3 and i just tested it on my test boxes, i will put it on the tree after the meeting
[22:38:59] <Zorry> k
[22:39:30] <prometheanfire> blueness: I believe pipacs wanted to add a last minute fix, I do not know how severe it was
[22:39:41] <zPenguin> zpenguin
[22:40:01] <blueness> the only other thing was whether to tweak the preset configs, SERVER, WORKSTATION and VIRTUALIZATION because some new hardened features came out, i'm going to leave them uset for now and let the users decide because they are a bit dangerous still and i don't want to force that
[22:40:38] <blueness> prometheanfire, it won't matter, i doubt this ebuild will ever go stable, i like have some ~ up there for testing and feedback to upstream
[22:40:47] <prometheanfire> ok
[22:40:53] <blueness> when i see a particular version which is least problematic, i stabilize it
[22:41:07] <blueness> eg 2.6.39-r8 was the last before the "compiler problems" started
[22:41:19] <blueness> it has no known issues
[22:41:28] <blueness> okay, that's it for kernel really
[22:42:05] <Zorry> k
[22:42:20] <Zorry> next then
[22:42:26] <Zorry> 5.0 selinux
[22:42:37] <SwifT> okay
[22:42:57] <SwifT> since last meeting, the newest userspace utilities (20110727) have been made available and are now in ~arch
[22:43:36] <SwifT> since I notice a few users complaining (non-gentoo) about its compatibility with the old refpolicy, I'm not going to mark that stable until refpolicy 20110726 is stable
[22:44:12] <SwifT> the 20110726 refpolicy-based selinux policy modules are in hardened-dev overlay; I'm planning to make a small update on them in a few days and then start migrating those to the main tree
[22:44:35] <SwifT> policy-wise, not that much has changed, but the ebuilds themselves have improved
[22:44:58] <SwifT> they're now EAPI=4 compliant, use a lot less cruft in files/ (thanks to reusing the patchbundle), show which patches are applied (and which ones failed in case one does)
[22:45:17] <SwifT> also, the selinux eclass has been updated to use proper comments inside (and to support EAPI=4)
[22:45:44] <SwifT> we are now also supporting MCS (and even MLS can be used, but we don't support that yet)
[22:46:31] <SwifT> when the migration of the selinux policy modules to ~arch (main tree) has been completed, I'll see if we can add support for sesandbox, a feature that fedora has that might be beneficial for others as well
[22:46:58] <SwifT> I'm also submitting the patches we have on the policy upstream
[22:47:18] <SwifT> that'll be quite a challenge, but a good one, since they are very careful about allowing things :)
[22:47:26] <SwifT> something about security folks ... :D
[22:48:10] <SwifT> for the time being, of the 52 patches I identified, 9 have been accepted, 7 are pending, 36 are yet to be submitted
[22:48:28] <SwifT> so at least I know what to do ;)
[22:48:45] <SwifT> the advantage of having them upstream is of course that the next release doesn't require the patches to be merged and maintained
[22:49:00] <prometheanfire> lazy is good
[22:49:27] <SwifT> that being said, like I said on the mailinglist, I'd like to switch from using gentoo_ prefixes for our own patches to just follow refpolicy style, otherwise I have to manually adapt all patches for upstream inclusion which takes a lot of time (and is error prone)
[22:49:50] <SwifT> it also breaks some of the tools/scripts available that use naming conventions as defined by refpolicy
[22:50:32] <SwifT> since I'm currently the only one doing that stuff (with gizmo having some experience on that as well), I think I can say I'll adapt the guideline (since we both had our say now ;)
[22:51:08] <SwifT> I think that's about it
[22:52:43] <Zorry> k
[22:52:48] <SwifT> questions?
[22:53:05] <Zorry> nope
[22:53:07] <blueness> yeah, i have no strong feelings on the issue so whatever you decide
[22:53:38] -*- prometheanfire has been very happy with responsivness to bugs submitted that are selinux related
[22:53:43] <blueness> SwifT, just one quick logistic question, did you move the patchbundle archive?
[22:54:03] <blueness> ie this -> http://dev.gentoo.org/~blueness/patchbundle-selinux-base-policy/
[22:54:06] <SwifT> blueness: all patchbundles that you had are now in my space as well, yes
[22:54:16] <SwifT> including your gpg signature just in case :)
[22:54:21] <blueness> k so i don't have to worry about maintainng that
[22:54:33] <Zorry> :)
[22:54:36] <blueness> sure the gpg is just an automatic thing i do with all my patches
[22:55:00] <SwifT> I didn't copy your index.php though :p
[22:55:06] <blueness> no big deal
[22:55:08] -*- quantumsummers|a returns
[22:55:13] <quantumsummers|a> yes, I support Zorry
[22:55:19] <quantumsummers|a> as lead, in the case it matters'
[22:55:31] <blueness> SwifT, also, remember that doc you wrote for how to debug selinux polciies?  did you put it on the main web paged?
[22:55:42] <blueness> page
[22:55:47] <SwifT> blueness: I did, but it isn't linked yet
[22:55:56] <SwifT> blueness: prometheanfire is struggling with it for creating his phpfpm module
[22:55:56] <blueness> ah that's why i couldn't find it
[22:56:10] <SwifT> blueness: but prometheanfire 's problem is that he doesn't like to read :p
[22:56:21] <prometheanfire> yes, I tend to jump in too fast
[22:56:27] <blueness> he might say that you're too verbose :P
[22:56:31] <blueness> j/k
[22:56:35] -*- prometheanfire tries to cast himself in a better light
[22:56:45] <blueness> SwifT, when do you ever find time to blog on gentoo planet ?!?!
[22:56:46] <SwifT> I'll wait a bit and make some adjustments based on recent events (such as better patching) and then link it
[22:56:54] <prometheanfire> blueness: and me not enough so (as per my quiz)
[22:57:10] <SwifT> blueness: whenever I think I'm going to forget something :)
[22:57:14] <blueness> prometheanfire, yeah, don't be afraid of complete sentences!
[22:57:18] <SwifT> which reminds me to blog... :D
[22:57:31] <SwifT> but first have the planet admins use the correct feed
[22:57:44] <prometheanfire> next?
[22:58:00] <Zorry> yep
[22:58:02] <blueness> my problem is that i haven't been running enough production selinux systems to really get into feedback on the policies, so its good to get that info to users that do, and get feedback form then
[22:58:25] <prometheanfire> blueness: I'm running 3.5 right now
[22:58:35] <prometheanfire> more to come (up to about 10 I think)
[22:58:58] <blueness> yeah next, we're getting off topic
[22:59:04] <Zorry> 6.0 Profiles
[22:59:32] <blueness> well i marked the feature/selinux profiles stable
[22:59:47] <Zorry> nice
[22:59:52] <SwifT> yaay! everybody do /disco in their chat client !!
[23:00:07] <blueness> we had a tracker open to catch any problems, and there were zero blockers
[23:00:13] <prometheanfire> SwifT: fool me once
[23:00:13] <blueness> so i did
[23:00:22] <SwifT> ;)
[23:00:39] <blueness> Halcy0n caught a two problems because he runs repoman full on the whole tree a couple of times a day
[23:01:07] <blueness> and noticed problems with some game and one use flag on opencv.  after those were masked, there are now no known issues
[23:01:16] <SwifT> cool
[23:01:32] <blueness> the next step, if we want to go there, is to deprecated some of the older selinux policies in 6 months or so
[23:01:43] <blueness> this is so we don't have to duplicate policy maintenance
[23:02:01] <SwifT> I'll put that on our roadmap
[23:02:14] <blueness> because right now, modifications to selinux/v2ref and features/selinxu have to be mirrored
[23:02:23] <blueness> which is a bad place to be
[23:03:06] <blueness> and finally, since feature/selinux is stackable at the end of any profile, we might want to think if we want to support vanilla/selinxu
[23:03:33] <blueness> we could approach whoevers responsible for that and see, but if there's no community desire for that, then maybe we could just skip it
[23:03:56] <blueness> any questions?
[23:04:35] <SwifT> nope; like I said earlier, I don't mind supporting vanilla, but wouldn't start doing that until we have a question for it - it'll put some more pressure on testing and such which I'd like to avoid without additional development efforts
[23:04:55] <blueness> right
[23:05:10] <blueness> i don't see a need really
[23:05:15] <Zorry> +1
[23:05:31] <blueness> anyone in gentoo who wants security generally does a hardened toolchain + some grsec/pax + either rbac or selinux
[23:05:37] <blueness> those all seem to go together
[23:05:45] <prometheanfire> ++
[23:05:55] <blueness> even my desktops are hardened + targeted selinux
[23:06:09] <blueness> so who wants vanilla + selinxu? not sure
[23:06:22] <prometheanfire> gamers?
[23:06:35] <blueness> gentoo for gaming?!
[23:06:37] <prometheanfire> anyone who wants to use anything binary
[23:06:46] <prometheanfire> I did for a while
[23:06:49] <prometheanfire> we do exist
[23:07:44] <prometheanfire> for instance, if you want to use vmware server you cannot use hardened at all (don't know if it is hard masked everywhere or just hardened though)
[23:07:54] <blueness> okay if there's nothing else on profiles, excuse me for a sec, my dog has been pestering me for about 30 mins ... time to feed him ... be back in 5 mins
[23:08:10] <Zorry> blueness: k
[23:09:09] <Zorry> hmm no klondike yet :(
[23:10:41] <prometheanfire> 7?
[23:11:46] <Zorry> we have docs after the profiles and no klondike :(
[23:11:59] <quantumsummers|a> Zorry: sorry I had to run to my data center to kill a problem
[23:12:08] <Zorry> quantumsummers|a: np
[23:12:15] <SwifT> well, on the selinux docs, the handbook has been updated with the MCS information
[23:12:35] <SwifT> it also refers to a workaround for a nasty segfault issue we have with tmpfs & selinux support (bug still open, but fix available)
[23:13:22] <SwifT> the SELinux FAQ has also been expanded (version mixing issues, undefined permission bootup error)
[23:13:33] <SwifT> I'll push the updated FAQ to the site after the meeting
[23:13:44] <blueness> back
[23:14:08] <Zorry> blueness: finich with the profiles ?
[23:14:14] <blueness> Zorry, yes
[23:14:26] <Zorry> okey docs then
[23:14:39] <Zorry> SwifT: do yo have some more?
[23:14:53] <SwifT> not for hardened (for GDP otoh, ... ;-)
[23:15:10] <Zorry> k
[23:15:25] <Zorry> i don't have anything
[23:15:39] <Zorry> and klondike is not here
[23:16:03] <Zorry> so jump to 8.0 Bugs
[23:16:14] <blueness> let me just say, i'm impressed by the doc work SwifT has done ... kudos
[23:16:26] <Zorry> SwifT: .+1
[23:16:31] -*- prometheanfire gives swift all of his kudos
[23:16:34] <prometheanfire> all 10 of them
[23:16:53] <SwifT> oh noes, not your kudos !!
[23:16:55] <SwifT> =)
[23:17:37] <SwifT> on selinux bugs, bug #375475 is annoying me
[23:17:40] <willikins> SwifT: https://bugs.gentoo.org/375475 "SELinux newrole launched shell does not behave as login shell (regression)"; Gentoo Linux, Hardened; CONF; sven.vermeulen:selinux
[23:18:10] <SwifT> Anarchy might find some time to check that out (he had some idea where the issues were)
[23:18:11] <blueness> SwifT, we complained non stop about doing docs cause we are just slackers when it comes to docs
[23:18:40] <SwifT> blueness: yes, and for prometheanfire, I'll make quickstart-* documents :)
[23:18:41] <prometheanfire> also, related to bugs, I've been sending bugs to swift and he has been awesome there too
[23:19:06] <prometheanfire> SwifT: awesome, just need refrences as to common things to put in fc te and the like
[23:19:15] <SwifT> bug #373381 is a somewhat more critical one for selinux, with a fix included /and/ accepted by upstream
[23:19:17] <willikins> SwifT: https://bugs.gentoo.org/373381 "sys-apps/util-linux-2.19.1 mount utillity segfaults under SELinux with v2ref profiles"; Gentoo Linux, Core system; CONF; gizmo:base-system
[23:19:43] <blueness> yep i just got a dup of that
[23:20:00] <SwifT> blueness: btw, bug #376385 - mind if I take that one from you?
[23:20:02] <willikins> SwifT: https://bugs.gentoo.org/376385 "sys-apps/policycoreutils: binary file in gentoo-x86/"; Gentoo Linux, Ebuilds; CONF; mattst88:blueness
[23:20:24] <blueness> not at all
[23:21:40] <SwifT> other than those, no specific bugs to report
[23:21:51] <prometheanfire> SwifT: I get a diferent error, I'll put it in the bug
[23:25:57] <blueness> the only big bug in kernel land is the one i mentioned above
[23:26:17] <prometheanfire> SwifT: any progress on bug 379323
[23:26:20] <willikins> prometheanfire: https://bugs.gentoo.org/379323 "sec-policy/selinux-asterisk does not allow socket connections"; Gentoo Linux, Hardened; IN_P; mthode:swift
[23:26:20] <blueness> all others have been fixed.  a blocker for 2.6.39 was the parallel builds with the pax_plugin, that's fixed
[23:26:42] <SwifT> prometheanfire: it was put on hold (first wanted to know how upstream thought about it)
[23:26:46] <blueness> haven't looked at that one
[23:27:20] <SwifT> prometheanfire: i'll work on it further in the next few days (already have 3 fixes for that in -r3)
[23:27:33] <SwifT> err, 5 fixes
[23:27:45] <prometheanfire> SwifT: ok :D
[23:28:08] <SwifT> it starts, I can stop it as well ;-) and I can run asterisk -r too
[23:28:20] <SwifT> just need to find a small tutorial where I can see a few tasks to test out
[23:28:33] <prometheanfire> SwifT: if it is in your overlay I can test
[23:28:36] -*- SwifT likes to script test cases for services
[23:28:41] <SwifT> it is
[23:28:47] <prometheanfire> ok
[23:28:49] <SwifT> all my test servers pull from my overlay
[23:29:13] <SwifT> just "emerge -1 selinux-base-policy selinux-asterisk" and "rlpkg -a -r" ;-)
[23:29:37] <prometheanfire> I do it via ebuild :P
[23:30:07] <SwifT> before releasing -r3 I would like to send out most (if not all) our dontaudit patches as well (12 more patches for upstream)
[23:30:17] <prometheanfire> SwifT: I'll give you some commands to run in the future
[23:30:21] <SwifT> k
[23:30:39] <prometheanfire> easily scripted
[23:31:50] <blueness> should we move to the next topic?
[23:32:17] <prometheanfire> I can give results of my tests now if you'd like
[23:32:35] <SwifT> the next topic was also for klondike
[23:32:42] <SwifT> something about him wanting to use twitter
[23:32:52] <blueness> what was it about?  Media = twitter?
[23:33:05] <Zorry> blueness: yes the twitter stuff
[23:33:46] <Zorry> the info was mail at hardened@
[23:33:49] <blueness> good idea to get the word out ... but personally i don't tweet ... tweeting is for the birds!
[23:33:58] <prometheanfire> blueness++
[23:33:59] <blueness> Zorry, yeah i remember now
[23:34:18] -*- SwifT has a twitter account, but hardly tweets... I do read the tweets of others from time to time
[23:34:23] <SwifT> it's like the good old days
[23:34:28] <SwifT> when birds could still talk ;-)
[23:35:14] <blueness> and male cows named Larry gave milk
[23:35:27] <SwifT> ewwww
[23:35:56] <blueness> yeah, that's what i say
[23:36:08] -*- blueness thinks this meeting has just ended :)
[23:36:32] <Zorry> yep
[23:36:35] <prometheanfire> SwifT: asterisk is working for me
[23:36:40] <Zorry> 10.0 open floor
[23:37:02] <Zorry> SwifT: congrat to be a dev
[23:37:21] <Zorry> ty for the trust
[23:37:21] <SwifT> thanks
[23:38:11] <prometheanfire> SwifT: staff_t should not have access? if that is true, then everything checks out good.
[23:38:19] <Zorry> meeting done then