Meeting log from the meeting
/Magnus
[22:09:20] <Zorry> okay lets start then
[22:09:45] <Zorry> 1.0 Toolchain
[22:10:44] <Zorry> have updated the piepatchset to 0.5.4 for gcc-4.7.2 to fix bug 436924
[22:10:52] <blueness> back
[22:11:00] <blueness> (gas meter dude)
[22:11:38] <blueness> does 0.5.4 still apply cleanly to gcc-4.6.3?
[22:11:46] <Zorry> the gcc upstream patches is on http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html
[22:12:03] <Zorry> blueness: did only change the 4.7.2 patch
[22:12:08] <blueness> k
[22:12:58] <Zorry> got alot of feedback on the patches :)
[22:13:21] <Zorry> have one thing left to fix is the crosscompile stuff
[22:13:39] <Zorry> will fix it this week i hope
[22:14:04] <Zorry> so i hope it get in after that
[22:14:21] <lejonet> Zorry: o/
[22:14:34] <Zorry> gcc-4.8 stage1 will mostly end in october
[22:15:42] <Zorry> so hope gcc-4.8 get the espf
[22:15:54] <blueness> this is good news, who has to sign off still?
[22:16:15] <Zorry> so we will add more arch later to it
[22:16:41] <Zorry> blueness: some gcc dev
[22:16:59] <Zorry> don't have gcc commit acces :(
[22:17:46] <Zorry> that is all from me
[22:17:55] <Zorry> blueness: your turn
[22:18:10] <blueness> Zorry, every arch i've tested is okay with 0.5.4 + gcc-4.6.3, if it is okay with 4.7.2 then you can add ppc, mips and arm
[22:18:35] <blueness> okay i've been thinking about what to do with all these "extra" ports of hardened
[22:19:04] <blueness> there is no common factor between them except 1) they are hardened and 2) they are exotic libc's, or arch's
[22:19:18] <blueness> and 3) various abis for those arches
[22:19:36] <blueness> so i'm thinking of creating an umbrella sub project to just track them all
[22:19:49] <blueness> a page which lists what we've ported hardened toolchain to
[22:20:18] <blueness> the only thing i can thinkg of is "Hardened Alt" for alternative systems that have been hardened, with a nice chart showing what's been done and what hasn't
[22:20:55] <blueness> as Zorry cleans up the espf patches, they are working well under many alternative libcs/archs/abis
[22:21:21] <blueness> and we can even start to jettison the stage4's i've been building for legitimate stage3's built with catalyst
[22:21:45] <blueness> so we have our own "release" team ... hence the subproject
[22:21:50] <blueness> what do you think?
[22:21:58] <blueness> i'll try to put up a page over the weekend
[22:22:09] <blueness> comments?
[22:22:33] <Zorry> it sound fine with me
[22:22:36] <klondike> looks like
[22:23:12] <blueness> Zorry, originally i was thinking sub -embedded but 1) they are pretty quiet and 2) not everything fits there
[22:23:24] <blueness> eg the work on hardened lemote yeeloong deskopt
[22:23:33] <SwifT> i'm ok with a separate subproject for it
[22:23:50] <blueness> = hardening + mips64el + glibc + 3 abi's o32, n32, n64 <- where does that fit!?
[22:24:10] <klondike> blueness: I think this could just fill well inside hardened
[22:24:12] <blueness> thanks, mostly i want to have a page with tracks it
[22:24:21] <blueness> lol klondike yeah
[22:24:30] <klondike> As long as we keep a state tracker of what is supported there
[22:24:49] <klondike> I think having some sort of hardened features matrix could do well the tryck
[22:25:03] <blueness> yeah but we also need to releng machinery
[22:25:16] <blueness> which is coming together
[22:25:38] <blueness> okay that's all from me
[22:25:39] <klondike> So how said releng is different from what jmbsvicetto did already with hardened stages?
[22:25:55] <blueness> klondike, these are not buildable right now with catalyst
[22:26:02] <blueness> for many reasons
[22:26:17] <blueness> and if the are to move to catalyst, it would be on native hardware
[22:26:26] <blueness> not crosscompiling which has its own issues
[22:26:53] <blueness> arm is about the closest, but none of the others would cross compile
[22:26:57] <blueness> maybe one day
[22:27:07] <klondike> *shrug* it may be the fever but I still don't see the need for the project
[22:27:25] <blueness> sub project = a way of organizing/focusing an effort
[22:27:35] <blueness> fever?
[22:27:43] <SwifT> it's little more than a way to segregate and consolidate data into a "container" for ease of management
[22:27:54] <klondike> blueness: have flu
[22:28:05] <blueness> yes more or less, right now its work that is scattered
[22:28:08] <blueness> without a home
[22:28:30] <klondike> Well if you feel the need for a subproject go for it, but how will we decide what's exotic and what isn't?
[22:28:59] <blueness> klondike, no algorithm exists, what is exotic today will be the norm tomorrow, human judgment :)
[22:29:04] <SwifT> if it runs grsecurity, it's not exotic :p
[22:29:09] <blueness> hahaha!
[22:29:11] <klondike> lol
[22:29:17] <Zorry> :D
[22:29:48] <blueness> let me write the page and show it to you before putting it up
[22:30:10] <blueness> you'll see that its as swift said, a segreagtion and consolidation
[22:30:11] <klondike> blueness: will you need transformation to Project/GuideXML?
[22:30:34] <blueness> klondike, i've been getting better at it, i may use gentoo-hardened/doc stuff
[22:30:52] <klondike> Oki if you need a hand just ping
[22:30:52] <blueness> okay let's not linger over this
[22:30:57] <blueness> ty
[22:31:37] <Zorry> some one else have something?
[22:31:43] <Zorry> next else
[22:32:05] <Zorry> 2.0 Kernel
[22:32:37] <Zorry> blueness pipacs ^^
[22:33:01] <blueness> some major improvements on virtualization + pax
[22:33:03] <blueness> that's for sure!
[22:33:16] <SwifT> configuration, or performance?
[22:33:20] <prometheanfire> kernexec and uderef don't impact perf in 3.5.4-r2 and above (somewhat in r1, but r2 solves another bug as well)
[22:33:27] <blueness> pipacs fixed a long standing bug with uderef and kernexec
[22:33:34] <blueness> yeah ^^^ as prometheanfire said
[22:33:41] <prometheanfire> because he's awesome :D
[22:33:42] <klondike> With all the processors?
[22:33:52] <SwifT> nice
[22:33:54] <blueness> prometheanfire, what have you tested?
[22:33:56] <klondike> I mean even older Intel work?
[22:33:58] <pipacs> only intel should have been affected i think
[22:34:04] <Zorry> pipacs: good work
[22:34:05] <SwifT> so we can have it enabled on both guest and host now?
[22:34:07] <pipacs> amd does svm differently
[22:34:08] <prometheanfire> I don't have old non-nested pages procs
[22:34:19] <pipacs> SwifT, yes
[22:34:29] <pipacs> well, with the caveat for uderef in general
[22:34:30] <pipacs> :P
[22:34:37] <blueness> do we know if the problem is still there for AMD?
[22:34:54] <pipacs> blueness, i checked the svm code and it didn't seem to be affected
[22:34:55] <prometheanfire> can't test :(
[22:34:56] <blueness> has anyone tested AMD?
[22:35:01] <blueness> k
[22:35:01] <pipacs> so i'd say amd was always fine
[22:35:11] <pipacs> but i'd like to hear confirmation from hw owners
[22:35:40] <blueness> right, actually pipacs i think you're right because on one of my home boxes, and amd, i never saw the problem, but it was an ancient 2008 AMD
[22:36:01] <blueness> so we should be good!
[22:36:34] <blueness> prometheanfire, pipacs correct me if i'm wrong but you also solved the "all memory committed at once" problem
[22:36:45] <SwifT> I was just about to ask about that one :p
[22:37:27] -*- klondike can try a really old core 2 when back home in December
[22:37:40] <pipacs> blueness, correct
[22:37:52] <Zorry> nice :)
[22:37:55] <pipacs> at least the non SANTIZIE related one
[22:38:05] <blueness> right
[22:38:07] <pipacs> SANITIZE works as expected :)
[22:38:13] <blueness> right!
[22:38:31] <blueness> if you sanitize the memory excpect it to get allocated
[22:39:12] <blueness> prometheanfire, okay you said -r1 and better -r2 so should i be looking to stab -r2 soon?
[22:39:38] <blueness> i just picked -r1 because it had the fix and was older (ie had more community testing)
[22:40:15] <klondike> blueness just let -r2 be and get some testing
[22:40:43] <blueness> klondike, i'd still like to hear prometheanfire's experience in comparing the two
[22:41:00] <blueness> prometheanfire, ^^ ?
[22:41:31] <lejonet> pipacs: I am working on getting my AMD magny cours box up and running, I did intend to create 4 different kernels for it and try the 4 combos of uderef and kernexec, but I also decided to try ZFS so creating more kernels became a pita and my time started to get om nom nommed by work and school :)
[22:41:36] <lejonet> :(*
[22:41:42] <pipacs> btw, we've stopped supporting 3.5 and are on 3.6 now
[22:42:00] <blueness> pipacs, not a problem really 3.5 -> 3.6 isn't that big a leap
[22:42:16] <klondike> lejonet: looks like you just need me to pay you a weekend visit after exams :P
[22:42:17] <pipacs> you'd think so ;P
[22:42:31] <lejonet> klondike: no :P
[22:42:34] <blueness> oh? what did they do behind the scened?!
[22:42:38] <blueness> scenes
[22:42:39] <klondike> That way I cook and you fix things :P
[22:42:40] <SwifT> 3.7 will be so much better :p
[22:42:42] <pipacs> lejonet, just test one kernel with everything enabled ;)
[22:43:12] <lejonet> pipacs: iirc that is what I currently have, let me double check, and I could put up a VM for quick testing
[22:43:52] <blueness> (brb again! anyhow i'm done with kernel)
[22:44:26] <Zorry> any one else?
[22:44:42] <lejonet> pipacs: yeah, got both kernexec and uderef turned on
[22:45:21] <Zorry> okay next
[22:45:29] <Zorry> 3.0 Selinux
[22:45:43] <SwifT> k
[22:45:52] <SwifT> so, first of all, we now have live ebuilds in hardened-dev overlay
[22:46:05] <SwifT> these pull the latest changes from our git repository so that we can easily and quickly test latest additions
[22:46:26] <SwifT> with prometheanfire having commit rights to the policy, that (together with another topic I'll hit soon) should allow us quick deployment of new updates
[22:46:36] <SwifT> it also gives me some relief of pressure ;)
[22:47:03] <SwifT> so for the adventurous (sp?), install the -9999 ebuilds for the policy and cry on this channel for help =-)
[22:47:13] <Zorry> :)
[22:47:22] <SwifT> second - you'll notice that there's a *lot* *more* activity than before on the policies
[22:47:47] <SwifT> that's because fedora (well, dominick grift actually) has commit rights upstream in refpolicy, and he's pushing the fedora patches to the refpolicy repository
[22:47:59] <SwifT> in about a dozen patches per day or so
[22:48:16] <SwifT> which, given the earlier "updates" in refpolicy of a few patches per week, is a fairly different ballgame
[22:48:33] <SwifT> until now, the patches made are those I also agree on (and our users will appreciate)
[22:48:46] <SwifT> however, I'm screening them too because there will be patches that I don't agree with as much
[22:49:15] <blueness> is he moving too fast for us?
[22:49:26] <SwifT> once I notice a (bigger) patch that uses a different principle than I have, and I can't get it settled on the refpolicy mailinglist itself, i'm going to discuss it on [email protected] to see if others agree with me or not
[22:49:32] <SwifT> well, he is if I'm on vacation
[22:49:37] <prometheanfire> blueness: r2 has the all mem commit fixed
[22:49:56] <SwifT> otherwise, merging the patches is fairly easy (I pulled in about 250 patches/commits in 2 days)
[22:49:58] <prometheanfire> meetings :|
[22:50:25] <SwifT> of course, the more patches I (and we) don't agree with, the more difficult it might become to merge them. But until now, no real hassle on it
[22:51:02] <SwifT> ok, another thing on the policies, is that rev5 is now in the main tree (~arched)
[22:51:16] <SwifT> I'm probably going to stabilize it tomorrow or so (14 days after hitting the tree, as discussed earlier)
[22:51:28] <SwifT> as people have pointed out, we're always running a bit behind on the facts
[22:51:39] <SwifT> stable packages, like postfix, require newer policies that we just wrote
[22:52:08] <SwifT> this is because most developers don't run with SELinux, so we only trap it when it hits stable, or when a user points it out to us in ~arch
[22:52:14] <blueness> SwifT, use your best judgment, dealing iwth fast moving upstreams is an art
[22:52:30] --> alunduil_ (alunduil@nat/rackspace/x-zifzsqiwwsjxohez) has joined #gentoo-hardened
[22:53:01] <SwifT> yes, well, when dealing with security policies, i'm often fairly... "specific" in my thoughts ;)
[22:53:12] <SwifT> hence the discussion I'd like to elicit on the mailinglist when it happens
[22:53:37] <SwifT> the xdg (vs gnome) stuff is probably one you'll see soon - i'll explain the problem them in more detail on the mailinglist, no need to hold this meeting on any further
[22:53:48] <blueness> SwifT, what is your test base like, i mean are there poeple who just all over the ~arch and report quickly
[22:53:50] <blueness> ?
[22:54:00] <prometheanfire> SwifT: I did get grift to admit that phpfpm should probably be seperate
[22:54:18] <prometheanfire> blueness: I run ~arch selinux only
[22:54:18] <SwifT> blueness: there are two users that are fairly good at reporting things, but they don't have every possible service running
[22:54:22] <SwifT> prometheanfire: cool
[22:54:53] <blueness> i have people that test as soon as hardened-sources hits
[22:54:55] <SwifT> I had a fairly elaborate test bed, but since the commit issue + one of my systems dieing on me, I had to reduce it again :(
[22:55:05] <SwifT> (commit issue == memory commit
[22:55:23] <prometheanfire> SwifT: how much space do you need?
[22:55:28] <SwifT> I used to run 7 kvm guests with a lot of services to "play" with, but it was reduced to 1 "play" environment lately
[22:55:42] <SwifT> space isn't an issue... memory & cpu usually is
[22:55:43] -*- prometheanfire has a tiny personal cluster now
[22:55:51] -*- SwifT has 47 TiB of storage :p
[22:55:56] <SwifT> anyway, back on track
[22:55:59] <prometheanfire> well, how much of that do you need for testing?
[22:56:25] <SwifT> I'm first going to check with the latest kernels that don't have the memory commit issue anymore
[22:56:39] <SwifT> anyway, on the selinux policies again
[22:57:04] <SwifT> because of the many, many patches that are going in, I am considering changing our patchbundle from a "per change" patch towards a more "all-in-one" patch
[22:57:15] <SwifT> the reason is that it takes portage a while to apply all the patches individually
[22:57:30] <SwifT> emerging a simple policy almost gives 30% of time patching
[22:57:44] <SwifT> with an "all in one" patch approach, this is significantly reduced
[22:57:59] <SwifT> the reason I used single patches was to make it easier to send them upstream
[22:58:18] <SwifT> but I can easily manage the single patches separate from the patch bundle, giing better experience to our users
[22:58:46] <SwifT> also, it'll allow other developers, like prometheanfire, to make releases (patchbundles) themsleves, since they only need to diff between our policy repository & the current stable refpolicy release
[22:59:21] <SwifT> also, rev 6 will hit the overlay (hardened-dev) soon, probably tomorrow
[22:59:33] <SwifT> and finally (last point for selinux, i promise ;)
[22:59:38] <blueness> SwifT, you seperate individual patches on a git repo, you push out many commits in one patch
[23:00:01] <SwifT> the latest release of userspace utilities for SELinux (2012-09-24) is also in hardened-dev overlay now
[23:00:33] <SwifT> blueness: well, since the "base" for the ebuilds isn't a specific point in time of our own repository, that's not a possibility
[23:00:49] <SwifT> blueness: perhaps in the future I'll detach from refpolicy releases and just use snapshots of our policy
[23:00:55] <blueness> SwifT, you mean a seperate repo
[23:01:03] <blueness> you make a separate repo
[23:01:18] <blueness> or a separate branch
[23:01:22] <blueness> in hardened-dev
[23:01:43] <SwifT> blueness: yes well, I'm currently making branches locally for the refpolicy tree, then commit in our tree, do tests and if it works, suggest the changes for refpolicy upstream
[23:02:05] <blueness> aha! you're already do it locally!
[23:02:13] <SwifT> but since a lot of our patches depend on patches that aren't accepted yet (xdg patch comes to mind) I have about 40 patches waiting :(
[23:02:37] <blueness> SwifT, exactly why i'm suggesting a repo for that queue
[23:02:44] <blueness> otherwise it gets unmanageable
[23:03:11] <SwifT> blueness: the easiest is to stick with refpolicy then... perhaps I should indeed use a brand new clone, apply there and continuously rebase as refpolicy goes along
[23:03:16] <blueness> anyhow my two sense, experience from dealing with patches from grsec every few days
[23:03:22] <SwifT> =)
[23:03:37] <SwifT> i'll take it up later, thanks for the suggestion
[23:03:43] <blueness> right, you just rebase when you accumulate enough
[23:04:00] <blueness> whatever works for you of course
[23:04:17] <SwifT> also, while we're still on SELinux... I also added a FAQ entry on how to reload the entire policy
[23:04:30] <SwifT> that's it for SELinux from me
[23:04:37] <prometheanfire> I have nothing else
[23:05:04] <Zorry> okay next
[23:05:19] <Zorry> 4.0 Grsec/PaX
[23:05:53] <Zorry> blueness ^^
[23:06:03] <blueness> okay pax, yeah
[23:06:16] <blueness> well i've been slacking or overworked with teaching
[23:06:21] <blueness> you choose
[23:06:29] <blueness> but here's what needs to be done
[23:06:41] <blueness> we're moving towards xattr pax flags but before we do
[23:06:52] <blueness> 1) i have to update pax-utils.eclass ... this should be pretty easy
[23:07:17] <blueness> we would test for the utilities we have to set pax on *both* PT_PAX header and xatter
[23:07:19] <blueness> in some order
[23:07:27] <blueness> and then make sure both are set consistently
[23:07:30] <blueness> easy enough
[23:07:55] <blueness> 2) we need tmpfs to support the user name space for xattr, Diego pointed this out
[23:08:13] <blueness> i looked at that code, i see roughly how to do it, but since its a kernel patch, we must proceed cautiously
[23:08:44] <blueness> pipacs and others have suggested i email the authors of the current patch against tmpfs to support the security.* namespace
[23:09:02] <blueness> which is probably the best thing to do to avoid making some classic blunder on my part
[23:09:55] <blueness> 3) then I need to document: a) what the possibilities are and how to migrate from pure PT_PAX to either a mix or pure xattr pax and 2) how to work with xattre pax
[23:10:05] <blueness> then 4) drink a beer, we're done
[23:10:29] <blueness> there's some pressure from vapier to get this work done because he wants to drop PT_PAX from the toolchain ie binutils
[23:10:45] <blueness> when/if he does, that means pure xattr pax!
[23:11:04] <blueness> which is a bit scary, but we'll move slowly on this
[23:11:13] <blueness> comments? suggestions? flames?
[23:11:40] <pipacs> i don't think he/you can drop pt_pax_flags anytime soon, there're existing binaries to support, not to mention filesystems taht don't support xattrs
[23:11:55] <Zorry> i think we need to fix the tmpfs before the eclass
[23:11:58] <blueness> pipacs, i'm with you on that for sure!
[23:12:26] <blueness> Zorry, both are a priority for sure, by why do you think tmpfs is critical?
[23:12:29] <Zorry> for alot of user compile in tmpfs
[23:12:30] <SwifT> once the time has almost come, i'm sure there'll be a tracker to follow up on what needs to be done
[23:12:33] <blueness> ah
[23:12:44] -*- prometheanfire compiles on tmpfs
[23:12:48] <Zorry> +1
[23:13:09] <blueness> Zorry, if pax-mark is done in pkg_postinst then there is no problem with tmpfs
[23:13:18] <blueness> but i dont like that hack
[23:13:32] <Zorry> blueness: some stuff need to be done in compile
[23:13:57] <blueness> oh you mean some compile time pax marking ... i remember that
[23:14:23] <blueness> okay i'll email the authors tomorrow and try to speed this one along
[23:14:53] <blueness> SwifT, there is already a tracker out
[23:15:04] <SwifT> ah k
[23:15:26] <SwifT> bug #427888
[23:15:27] <willikins> SwifT: https://bugs.gentoo.org/427888 "[TRACKER] Introduction of xattr based pax markings to Gentoo"; Gentoo Linux, Hardened; CONF; blueness:blueness
[23:15:34] <SwifT> willikins: botsnack
[23:15:35] <willikins> SwifT: thanks :)
[23:15:59] <blueness> that's it for pax, about grsec, just a small report
[23:16:26] <blueness> i used to have various predefined setting for grsec, like HARDENED_WORKSTATION etc
[23:16:39] <blueness> this disappeared once brad changed all that kconfig code
[23:16:47] <blueness> i thought people would complain etc
[23:16:53] <blueness> but no one seems to mind
[23:17:12] <blueness> its actually a very nice system and our users took to it better than i thought they might
[23:17:34] <ccxCZ> I always hand-configured it
[23:17:40] <blueness> basically select the basic characteristics of your system: desktop vs server, efficient vs secure etc
[23:17:58] <blueness> then you get the default but then you can always tweak the default
[23:18:02] <blueness> vi custome
[23:18:18] <ccxCZ> one needs to make sure the hardenings one enables don't collide with anything, so you walk through them one by one anyway
[23:18:27] <blueness> yeah ccxCZ you get the best of both worlds this way, nothing stops you from hand-configuring it after that
[23:19:25] <blueness> ccxCZ, i always had configure everything, but its nice to see what upstream thinks is a typical "workstation" "secure over pref" "virtualization" is all about
[23:19:58] <blueness> anyhow, i just wanted to summarize by saying that the new grsec kernel config menu is a winner
[23:20:02] -*- blueness is done
[23:20:14] <SwifT> first you were greedy, then a poet, and now you're done
[23:20:25] <Zorry> lol
[23:20:27] <blueness> SwifT, i'm complex!
[23:20:45] <Zorry> someone else?
[23:20:51] <Zorry> next then
[23:20:54] <ccxCZ> I'm pretty much always using it with conjunction with vserver anyway
[23:21:03] <Zorry> 5.0 Profiles
[23:21:29] <blueness> very important announcement! ... nothing has changed :)
[23:21:52] <SwifT> I'm going to start removing the older selinux ones soon
[23:21:54] <ccxCZ> I guess I'll wait a while to see next official release of that anyway
[23:22:02] <blueness> SwifT, do it! seriously
[23:22:05] <SwifT> probably going to start with the necessary announcements next week
[23:22:48] <SwifT> but that's it as far as announcning anything for profiles is concerned ;)
[23:23:29] <SwifT> next?
[23:23:32] <blueness> c'mon who uses this -> selinux/2007.0
[23:23:42] <SwifT> blueness: it's retro ;)
[23:23:46] <blueness> totally
[23:23:50] <prometheanfire> totally hipster
[23:23:57] <blueness> like
[23:24:00] <blueness> :)
[23:24:01] <SwifT> almost steampunk
[23:24:14] <SwifT> ok, Zorry, hit the next topic ;)
[23:24:16] <blueness> my wife loves steampunk, but we digresss ... NEXT!
[23:24:34] <Zorry> 6.0 System interity
[23:24:39] <SwifT> ok
[23:24:56] <SwifT> well, the first focus of the integrity project is to support protecting images or disks from offline tampering
[23:25:11] <SwifT> you know, people mounting your drives or images and changing stuff you don't want to see changed
[23:25:31] <SwifT> one way of doing that is through Linux' IMA subsystem (Integrity Measurement soemthing - Architecture?)
[23:25:45] <klondike> Verity?
[23:26:03] <SwifT> ima is a functionality that registers the checksum off files (including application code) before it is executed or read
[23:26:32] <SwifT> together with TPM support (that chip on many systems) it can provide proper attestation for the state of a system
[23:26:50] <SwifT> I'm currently writing the documentation for IMA within Gentoo (@ http://www.gentoo.org/proj/en/hardened/integrity/docs/ima-guide.xml)
[23:27:14] <SwifT> also, there are a few ebuilds (packages) needed for the support, which are currenlty in my own overlay but will be moved to hardened-dev when some more testing is done
[23:27:35] <SwifT> also, with an additional kernel patch, IMA allows the system to take action when the checksum of a file or application doesn't match the registered one
[23:27:49] <SwifT> the checksums are stored in xattrs, btw
[23:27:56] <blueness> i see that
[23:28:09] <SwifT> which brings me to the thing I'll work on when IMA is done - EVM ;) which is to protect the xattrs from being tampered
[23:28:24] <SwifT> that's also an important thing for SELinux as SELinux stores its labels in xattrs too
[23:28:52] <SwifT> now, the additional kernel patch I spoke about is targetd for inclusion in the main Linux kernel for 3.7 last time I heard
[23:28:58] <blueness> SwifT, are *all* xattrs protecte, including user.* ?
[23:29:17] <SwifT> so I'm probably not going to put much effort in trying to have it in earlier kernels since there's too much work to be done anyway
[23:29:23] <SwifT> blueness: I think only security.*
[23:29:29] <SwifT> blueness: but I'll check
[23:29:30] <blueness> damn
[23:29:43] <blueness> more reason why we might have gone security.pax.*
[23:30:15] <blueness> SwifT, if you have any sway, try to get *all* xattrs in there
[23:30:20] <klondike> SwifT: what about verity and its per block integrity measurement?
[23:30:23] <SwifT> anyway, when IMA/EVM is done, the next focus will be on something more people have experience with, nl file system encryption - which not only protects from offline tampering, but also offline reading
[23:30:23] <blueness> the other namespaces are important too
[23:30:43] <SwifT> klondike: that's also on the roadmap, but I haven't taken a good look at it yet as it's fairly new
[23:31:33] <SwifT> when the IMA and EVM stuff is done, I'll also release a new selinuxnode VM image on the experimental/ location which includes IMA/EVM stuff in it
[23:31:49] <SwifT> so people can play with that too
[23:32:06] <SwifT> that's it for integrity
[23:32:22] <Zorry> next then?
[23:32:32] <Zorry> 7.0 Doc
[23:32:33] <blueness> quick question
[23:32:47] <Zorry> blueness: go
[23:33:00] <blueness> SwifT, IMA/EVM are very nice and kernel level, but why are they improvments over aide or tripwire
[23:33:11] <blueness> ?
[23:33:27] <SwifT> blueness: they're kernel level; aide/tripwire are userland-level. It's where you put your trust in
[23:33:48] <SwifT> one major advantage I see is that IMA/EVM support the TCG's TPM
[23:34:15] <SwifT> so you can have remote systems "check" if your system is not compromised
[23:34:39] <blueness> SwifT, with aide/tripwire i can move the checksums off the drive or gpg sign on drive, looks pretty safe to me
[23:34:56] <SwifT> sadly, the TPM checks I can do are limited to a fake TPM (there's a driver for that) since the system with TPM I have access to, already have the TPMs taken ownership and I can't remove that
[23:34:57] <blueness> and for reading offline, encryption
[23:35:26] <SwifT> blueness: but how can a remote system verify if your system is not compromised?
[23:35:40] <SwifT> blueness: you can't just go show a tripwire report; it's easily fakeable
[23:35:47] <blueness> SwifT, gpg --verify list-o-checksums
[23:36:02] <SwifT> blueness: yes, and then you save that and always show the same list
[23:36:03] <blueness> md5sum -c lost-o-checkums against entire system
[23:36:23] <SwifT> blueness: with remote attestation, a nonce is sent together with the request for the list, and the list is generated + the signature of the TPM on that list + nonce
[23:36:44] <SwifT> but again, it's where you put the trust at
[23:36:57] <SwifT> I'm most likely going to document aide somewhere in the future too anyhow
[23:37:05] <blueness> SwifT, i look forward to mistrusting everything when you're ready to present :)
[23:37:22] <blueness> 3.7 is just around the corner
[23:37:25] -*- SwifT currently uses aide with integration in portage using portage' hooks... easy and auto-updating ;)
[23:37:31] -*- klondike wonders what would happen if somebody replaced the motherboard/TPM chip...
[23:37:59] <blueness> okay i'm done with my skepticism
[23:38:09] <blueness> i'm glad you're doing this SwifT
[23:38:16] <SwifT> it's fun to learn ;)
[23:38:25] <blueness> yeah i look forward to learning it from you
[23:38:52] <ryao> blueness: You might find this interesting: https://github.com/zfsonlinux/zfs/issues/1004
[23:38:54] <blueness> Zorry, go ahead with next
[23:39:01] <ryao> blueness: Apparently, there are people on Gentoo Hardened trying to build with GCC 4.3.4.
[23:39:08] <ryao> Well, trying to build the kernel with GCC 4.3.4.
[23:39:12] <Zorry> ryao: meeting
[23:39:22] <ryao> Zorry: Sorry about that. I will keep quiet then.
[23:39:29] <Zorry> 7.0 Doc
[23:39:36] <Zorry> SwifT: klondike
[23:39:48] <SwifT> nothing from my side (beyond the FAQ thingie mentioned earlier)
[23:40:18] <klondike> Zorry: I think I updated the Gentoo Hardened talk slides though I'm not sure if I uploaded them already or not
[23:40:43] <klondike> As always if any of you guys wants to talk on Gentoo Hardened are more than welcome to take them and use them
[23:41:06] <klondike> I need to update them for this new link TOCTOU for apache though
[23:41:07] <blueness> i have a serious TODO item: xattr pax. people could actually start using it now, but i need to explain it
[23:41:37] <klondike> blueness: the document lays there unfinished and I need to focus on my thesis this month
[23:42:02] <klondike> So as always please somebody pick it up and end it!
[23:43:59] <blueness> documentation has always been hard for us
[23:44:06] <Zorry> yep
[23:44:13] <blueness> maybe i can get twitch153|fulong to staff level and enslave him
[23:44:28] <Zorry> :)
[23:44:32] <blueness> he knows i could fail him in his courses, so i have lots of power
[23:44:34] <blueness> :)
[23:45:05] <blueness> heh, he's on his fulong = mips64el box :)
[23:45:10] <blueness> twitch153|fulong, get on here!
[23:45:25] <blueness> okay i think we're done
[23:45:38] <Zorry> next then
[23:45:45] <Zorry> 8.0 Bugs
[23:46:00] <Zorry> !bug 436626
[23:46:02] <willikins> Zorry: https://bugs.gentoo.org/436626 "dev-libs/libffi-3.0.x fail PROT_EXEC on hardened PaX Kernel"; Gentoo Linux, Hardened; CONF; zorry:hardened
[23:46:13] -*- blueness runs!
[23:46:24] <klondike> blueness: forming twitch153|fulong to write docs I can do if you want :D
[23:46:25] <Zorry> looks like upstream ignore the patch :(
[23:46:34] <SwifT> well, I have one I don't seem to be able to resolve properly too --> bug #436338 . Needs swig & tcl knowledge and I just can't get it working :(
[23:46:36] <willikins> SwifT: https://bugs.gentoo.org/436338 "apol does not work with setools-3.3.7-r5"; Gentoo Linux, SELinux; CONF; swift:selinux
[23:47:08] <blueness> Zorry, i'm not surprised about upstream and the libffi patch
[23:47:14] <klondike> SwifT: I may be able to tackle the swig one
[23:47:14] <Zorry> haven't talk to vapier yet
[23:47:19] <blueness> first its for pax and most teams don't care
[23:47:20] <klondike> I DO know tcl
[23:47:41] <Zorry> but we need that patch some way
[23:47:49] <blueness> second its a *particular* approach to our pax issue so even more so, its marginal
[23:47:55] <SwifT> klondike: well, i don't know if you still have a selinux system somewhere, but it's easy to test out (and confirm)...
[23:48:11] <klondike> SwifT: no selinux system :(
[23:48:20] <blueness> Zorry, yes it is the best current solution to our problems with python/ctypes/pax
[23:48:26] <Zorry> yep
[23:48:27] <klondike> But will check and if possible send you a fix for testing
[23:48:40] <blueness> Zorry, who do we have to convince within gentoo?
[23:48:52] <Zorry> vapier
[23:48:56] <Zorry> i think
[23:49:17] <blueness> <herd>toolchain</herd>
[23:49:18] <blueness> yep
[23:49:42] <blueness> do you have a lollipop? he might be bribed with that :)
[23:49:54] <blueness> Zorry, email him, or i can
[23:50:12] <Zorry> go for it
[23:50:18] <klondike> blueness: can't we just call the Chicago guys? :P
[23:50:21] <blueness> thanks :/
[23:50:35] <klondike> I really love the idea of horse heads on beds :P
[23:50:41] <blueness> klondike, first we'll try the lollipop, then the brute squad
[23:51:05] <blueness> Zorry, but then tehre's also the python patch no?
[23:51:26] <Zorry> blueness: not yet for we need the libffi fix befor that
[23:52:11] <blueness> okay
[23:53:10] <Zorry> and the libffi is in the overlay with the fix
[23:53:39] <blueness> okay
[23:54:01] <blueness> Zorry, i'll look, is the enable flag based on USE="pax_kernel"?
[23:54:20] <Zorry> yes
[23:54:22] <blueness> k
[23:54:39] <blueness> that should be safe enough, i thin mike will be okay with that
[23:56:16] <Zorry> hope he can push upstream
[23:56:30] <SwifT> if there's nothing else, I think i'll hit the deck for now
[23:56:39] <Zorry> SwifT: gn8
[23:56:43] <SwifT> nite flks
[23:56:44] <klondike> There is 9.0 media
[23:56:48] <SwifT> oh, sorry
[23:57:00] <Zorry> next then
[23:57:05] <Zorry> 9.0 media
[23:57:10] -*- SwifT had his phone complain about all the tweets already :p
[23:57:14] <klondike> But all I have to say there is we had a nice talk in Kosovo with a lot of attendance
[23:57:41] <klondike> So don't be sruprised if some Kosovians or Albanians show up around
[23:57:49] <SwifT> klondike: what was in kosovo? conference?
[23:57:50] <klondike> We also tweeted the meeting
[23:57:59] <klondike> SwifT: Flossk conference yes
[23:59:19] <Zorry> i will be on the gentoo miniconf october 20-21 in Prag
[23:59:36] <klondike> Zorry: want the slides to speak on Hardened?
[23:59:46] <Zorry> nope
[00:00:32] <Zorry> someone else?
[00:00:38] <klondike> Sorry that should have been an statement then :P
[00:00:56] <Zorry> next then
[00:01:06] <Zorry> 10:0 Open floor
