public inbox for gentoo-hardened@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-hardened] Logs from meeting 2011-04-20 20:00
@ 2011-04-25 18:55 Magnus Granberg
  0 siblings, 0 replies; only message in thread
From: Magnus Granberg @ 2011-04-25 18:55 UTC (permalink / raw
  To: hardened-dev, hardened-kernel, hardened, gentoo-hardened

[-- Attachment #1: Type: Text/Plain, Size: 46 bytes --]

Hi
Here is the log from the meeting.

/Magnus

[-- Attachment #2: meeting-2011-04-20_20:00UTC.log --]
[-- Type: text/x-log, Size: 14837 bytes --]

[22:12:25] <Zorry> okay lest start then
[22:12:42] <Zorry> is the agenda okay ?
[22:13:00] <blueness> yes
[22:13:12] <Zorry> blueness: yse we have alot of trolls
[22:13:22] <klondike> It is Zorry
[22:13:41] -*- Zero_Chaos comes out from under his bridge for the meeting
[22:13:48] <Zorry> okay
[22:13:59] <Zorry> 1.0 Toolchain
[22:14:20] <Zorry> gcc 4.6 is out in the tree but masked
[22:14:50] <Zorry> it did have some spec probs but it is fixed in newer gentoo patchset 1.2
[22:15:38] <Zorry> else i don't have that mutch to report
[22:16:03] <Zorry> still working on the upstream patchset to for gcc 4.7
[22:16:40] <Zorry> any one else have some thing to add ?
[22:16:43] <blueness> Zorry, what archs do our toolchain people (ditryepic vapier etc) test on?
[22:16:53] <blueness> do they test ppc ppc64 arm mips?
[22:17:37] <Zorry> blueness: most on x86 and amd64 i think but then we have the arch tester for more of the arches
[22:17:37] <blueness> i'm asking because i'm not sure what archs we support in hardened, x86 and amd64 for sure
[22:17:44] <blueness> k
[22:18:29] <Zorry> the pie patches is most only a bump now days 
[22:18:45] <blueness> right
[22:19:52] <Zorry> blueness: any thing else ?
[22:20:33] <blueness> Zorry, no, just that i think i should be more pro-active in testing the hardened toolchain on ppc pp64
[22:20:50] <blueness> no arch team tests hardened stuff
[22:21:04] <klondike> blueness: x86 amd64 arm ppc ppc64 ia64
[22:21:06] <blueness> i can do arm and mips but those are too slow
[22:21:15] <klondike> This is the arches oficially "supported"
[22:21:39] <klondike> arm are mips are suposedly in progress
[22:21:41] <blueness> klondike, yes but effectively we've only been supporting x86 and amd64
[22:21:56] <klondike> blueness: nobody asked for anything else either :P
[22:21:57] <blueness> klondike, i'm talking just hardened.
[22:22:03] <blueness> true
[22:22:26] <blueness> okay i think enough for toolchain
[22:22:39] <Zorry> need to get a hold of some arm dual core would be good :)
[22:23:24] <Zorry> blueness: we can test alot when i have the tinderbox stuff up and running
[22:23:35] <blueness> even cross?
[22:23:59] <Zorry> blueness: would not be that hard to do
[22:24:01] <blueness> ie cross compiled?  i'm not sure how the tinderbox help
[22:24:04] <blueness> k
[22:24:21] <Aleister> qemu supports arm emulation right+
[22:24:22] <Aleister> ?
[22:24:27] <blueness> yes
[22:24:50] <Aleister> so if that works it wouldnt be hard to setup a tinderbox instance by using that ...
[22:25:12] <Aleister> gotta be slow i guess :(
[22:25:19] <blueness> in kernel i've been trying to support 4 arches, but effectively i only got 3 clean: x86, amd64 and ppc64
[22:26:08] <Zorry> next ?
[22:26:13] <blueness> yes
[22:26:20] <Zorry> 2.0 Kernel
[22:26:27] <blueness> k
[22:26:42] <blueness> 3 short items:
[22:27:03] <blueness> 1) virtualization has problems again even with UDEREF and KERNEXEC off
[22:27:06] <blueness> in kvm
[22:27:22] <blueness> so i need to look into that and poke pipacs
[22:27:32] <blueness> seems to have started with .38
[22:27:59] <blueness> but .32 is okay so for those who do hardened kvm host, use that
[22:28:41] <blueness> 2) there is a corner case issue with an important driver in the kernel CCISS, the HP/Compaq SAS driver
[22:29:11] <blueness> i think i'm going to have to pull some commits from upstream and revert, it effects newer p410i driver
[22:29:24] <blueness> corner case but still important
[22:30:02] <blueness> 3) grsec/pax team have bumped to grsec 2.2.2 which includes some code change and new kernel options
[22:30:23] <blueness> a) randomization of kernel stack
[22:30:45] <blueness> b) pre-emptive kernel action against an exploit attack
[22:31:19] <blueness> both of them are untried and randstack is potentially dangerous, so i'm going to leave them off by default but can be turned on for all Gentoo predefined kernel options
[22:31:44] <blueness> within a day you'll be able to see them in 2.6.32-r44 and 2.6.38-r1
[22:31:51] <blueness> when i put them on the tree
[22:32:38] <blueness> the other one (i forget the name) simply locks out any user who tries the same brute force exploit mor than once
[22:32:58] <blueness> so if you get the same violation of UDEREF 3 times in a row, you  are locked out!
[22:33:05] <blueness> or if you are root, the system panics
[22:33:19] <blueness> potentially annoying so i'll leave it off by default
[22:33:38] <blueness> okay that's it for kernel summary, questions?
[22:34:02] <klondike> blueness: will you publish yesterday's patch or the one from 16 of april?
[22:34:17] <prometheanfire> I think I just ran into that dd bug a few min ago on 2.6.38
[22:34:18] <blueness> klondike, the very latest
[22:34:31] <blueness> there were some problems earlier with rpcstatd being killed.
[22:34:36] -*- klondike would apreciate the last 2 minutes of chat in private since he lost connection
[22:34:44] <blueness> klondike, of course
[22:35:07] <prometheanfire> is this still an outstanding issue?
[22:35:10] <blueness> kernel stuff recap -> http://dpaste.com/534099/
[22:36:22] <prometheanfire> blueness: also, that dd bug may make it hard for me to test
[22:36:48] <blueness> prometheanfire, see how far you get
[22:37:10] <prometheanfire> ok, I'll try to copy the VM to the laptop again soon
[22:37:18] <prometheanfire> I was using netcat | dd if that maters
[22:37:31] <blueness> k
[22:37:44] <prometheanfire> here is a link to a pic of the panic (still up) http://imgur.com/LbHKT
[22:38:33] <Zorry> can we discus it on the open floor ?   and move on
[22:38:34] <blueness> 2.6.38?
[22:38:40] <blueness> Zorry, yes
[22:38:52] <klondike> Cool I'll apply it to the slides too :D
[22:39:16] <prometheanfire> blueness: 2.6.38 with your bfs patch
[22:39:25] <prometheanfire> want me to shutup and discuss it later?
[22:39:35] <blueness> yes details later summaries now
[22:39:40] <prometheanfire> kk
[22:39:49] <prometheanfire> well, I hit that bug, whatever it is :D
[22:40:25] <Zorry> 3.0 Selinux SwifT gizmo blueness
[22:40:42] <SwifT> I'll go first (quickly) if people don't mind
[22:40:49] <blueness> plese
[22:40:52] <blueness> please do
[22:41:22] <SwifT> on the no-multilib profile: not much work since the suggestion on the mailinglist. My suggestion is to wait for the stabilization first, then get a draft suggested profile in git with PeBenito with it as well :)
[22:41:43] <SwifT> cause profiles isn't something I'd really like to touch (often)
[22:42:12] <blueness> (SwifT I think i actually understand profiles now and will help with nomulti)
[22:42:18] <SwifT> other than that, I'm planning to do some tests on higher version hardened kernels (.38 and so) in the next few weeks
[22:42:25] <SwifT> blueness: cool
[22:43:01] <SwifT> on the policy packages themselves, not that much has been changed lately (a few dontaudits here, an update on the portage stuff to support svn+src distfiles)
[22:43:40] <SwifT> the policy stuff updates should go up later though as I'm going to set up a few selinux systems with services that I haven't tested earlier :)
[22:43:59] <SwifT> that's all here on selinux (non-documentation), questions?
[22:44:04] <blueness> SwifT, yes
[22:44:14] <blueness> SwifT, i've been making changes to policies locally
[22:44:31] <blueness> i haven't suggested them because i'm still not 100% sure how to systematically debug policies
[22:44:48] <blueness> a short howto might be nice.
[22:45:03] <blueness> what i've been doing is in permissive mode, doing audit2allow
[22:45:08] <SwifT> yeah, ack on that, i'll write it down in my todo here
[22:45:19] <blueness> SwifT, k
[22:45:42] <blueness> that might be useful on klondike's docs because then we can get users to suggeswt policy updates
[22:45:56] <blueness> there are too many services for use to catch everything
[22:45:56] <SwifT> I don't frequent audit2allow that much to be honest, only in corner cases where I believe it is specific to my system (and not beneficial for others)
[22:46:04] <blueness> k
[22:46:22] <blueness> oh i have something else on Selinux
[22:46:34] <blueness> i've got ebuilds for setroubleshoot imported from fedora
[22:46:50] <blueness> there was an ebuild maintainer request so i cleaned up the ebuilds and put them on my overlay
[22:47:00] <blueness> may be useful if we ever get a full selinux desktop
[22:47:13] <blueness> i used to use it often when working with fedora
[22:47:18] <SwifT> definitely... even if it is just to get on track with #selinux :)
[22:47:33] <blueness> right
[22:47:56] <Zorry> blueness: maybe move that to the dev overlay ?
[22:48:00] <blueness> so the ebuilds are on my overlay for now ... setroubleshoot and setroubshoot-plugin
[22:48:09] <blueness> Zorry, yes i should
[22:48:23] <blueness> i use my overlay as a scratch pad, it belongs in dev overlay
[22:48:36] <blueness> i'll do that right after the meeting
[22:49:18] <Zorry> k
[22:49:23] <blueness> k i think that's it for me on selinux
[22:49:46] <Zorry> anyone else?
[22:50:13] <Zorry> okay 4.0 Profiles
[22:50:48] <Zorry> haven't done any change to it 
[22:50:56] <blueness> nope no changes on my end
[22:51:11] <Zorry> k
[22:51:17] <blueness> the last change made them much more clearer
[22:51:28] <blueness> i hope we don't have to touch them anytime soon :)
[22:51:33] <Zorry> yep
[22:52:31] <blueness> next?
[22:52:35] <Zorry> yep
[22:52:43] <Zorry> 5.0 Docs
[22:52:59] <prometheanfire> I've updated the virt docs slightly http://goo.gl/LRHDI
[22:53:11] <Zorry> we have updated alot of the selinux docs 
[22:53:47] <prometheanfire> added the table, cleared up the guest vs hosts kernel config for kvm and added some info on vmware
[22:53:57] <Zorry> :)
[22:54:20] <blueness> prometheanfire, thanks for that
[22:54:30] <SwifT> yup, and a few changes are also pending in the selinux handbook (cfr. hardened-docs.git) -> use of python 2 during installation, remove draft disclaimer, update on kernel configuration and inform about labelling swapfiles (bug #199609)
[22:54:31] <prometheanfire> I don't know too much, but I think the vmware description is correct
[22:54:31] <willikins> SwifT: https://bugs.gentoo.org/199609 "SELinux handbook should cover labeling swapfile"; Doc Other, Project-specific documentation; NEW; aross:selinux
[22:55:07] <klondike> Well I have done a cool slide set in spanish about how cool Gentoo Hardened is
[22:56:09] <klondike> Will be translated to english soon and published!
[22:56:09] <blueness> prometheanfire, yes that is at least true.  but i suspect there are even more problems with vmware
[22:56:17] <wao> klondike: show me!
[22:56:19] <wao> :D
[22:56:25] <klondike> wao: you can read spanish?
[22:56:34] <klondike> I'll do so after dinner :D
[22:56:36] <prometheanfire> blueness: almost definitely, I just do not have the expertise to test without handholding
[22:57:15] <blueness> prometheanfire, the only suggestion i would make is *strongly* emphasis the difference between hardening host vs hardening guest
[22:57:32] <blueness> vmware on a vanilla system (any distro) running a fully hardened guest is oaky
[22:57:51] <blueness> there is only one case where hardening the guest causes problmes what i know, xen paravirt
[22:57:58] <prometheanfire> the way I'd like to do that is to have a subsection for each virt type
[22:58:07] <Arach> Too much "DoS" vulns in solaris kernel...
[22:58:15] <blueness> but even with xen, full virt (ie hvm) you can do full hardening no problems
[22:58:19] <prometheanfire> ya, vmware should be updated more
[22:58:24] <Arach> I wonder if they're really just DoS...
[23:00:41] <Zorry> any thing else ?
[23:01:19] <SwifT> if possible, I'd like to see the selinux handbook as in git pushed to proj/hardened location ?
[23:01:43] <Zorry> SwifT: okay
[23:01:52] <blueness> SwifT, do you have commit to hardened-docs?
[23:02:03] <Zorry> can fix that in the weekend
[23:02:13] <Zorry> blueness:   not on cvs
[23:02:16] <blueness> oh you mean pushed to the cvs
[23:02:17] <blueness> right
[23:02:35] <blueness> Zorry, have you been doing that?
[23:02:56] <blueness> ie pushing docs for these guys
[23:03:07] <Zorry> blueness: yes i have proxy SwifT gizmo klondike changs
[23:03:21] <blueness> k
[23:03:22] <SwifT> buzy guy ;)
[23:03:31] <klondike> Zorry: did so, thanks a lot :D
[23:04:09] <Zorry> np
[23:05:20] <Zorry> next then ?
[23:05:23] <blueness> yep
[23:05:40] <klondike> go ahead
[23:05:40] <Zorry> 6.0 Bugs
[23:06:07] <Zorry> any bug we need disscus?
[23:06:33] <blueness> not a particular one, but i wanted to mention the elf thing i did
[23:06:57] <blueness> there are a family of bugs which have executable GNU_STACKS
[23:06:59] <Zorry> the xorg public glx bug is fixed upstrem
[23:07:06] <blueness> oh good
[23:07:42] <blueness> i traced down why some asm leads to RWX on GNU_STACK program entries of elfs
[23:07:57] <blueness> both yasm and nasm do that automatically
[23:08:11] <blueness> also there are many binaries which we can't fix the asm directly
[23:08:30] <klondike> I'm uploading the docs... wao http://klondike.xiscosoft.es/charlas/Hardened/
[23:08:57] <blueness> so i wrote code to mark any stack that is WX as just W and put the ebuild on the tree
[23:09:00] <blueness> sys-apps/elfix
[23:09:22] <Zorry> okay :)
[23:09:22] <blueness> this was in response to the p7zip bug, but i'm sure there will be others
[23:09:40] <blueness> it does exactly what execstack from perlink does, but without all the prelink stuff
[23:10:11] <Zorry> yes it will be when thay dont add the no rwx fix in the asm
[23:10:30] <blueness> just add that i plan to add others for fixing lazy vs bind now and otehr changes that can be made to elfs after compiling/linking
[23:11:09] <blueness> that's it
[23:11:19] <Zorry> k
[23:11:22] <klondike> Maybe we should write a guide on fixing common hardening bugs?
[23:11:43] <Zorry> we have that in the docs 
[23:11:52] <blueness> klondike, or even just identifying them, but we have instructions
[23:11:59] <blueness> lol mid air collision with zorry
[23:12:06] <Zorry> :)
[23:12:34] <klondike> Zorry: maybe some faq entries pointing to them
[23:12:52] <klondike> overflow bugs detected by fortify sources would also like a guide :P
[23:13:00] <blueness> klondike, yeah a table of contents of common problems pointint to where the fixes are
[23:13:39] <blueness> (guys i have to run right now but we're almost finished anything pressing before i leave)
[23:13:53] <Zorry> not from me
[23:14:18] <blueness> prometheanfire, SwifT regarding the bugs we discussed above, catch me later today or tomorrow
[23:14:23] <blueness> ta ta for now
[23:14:28] <prometheanfire> blueness: kk, I have to go too
[23:14:28] <SwifT> blueness: ack
[23:14:37] <prometheanfire> so, msg me also :D
[23:14:54] <prometheanfire> cya
[23:14:59] <Zorry> okay open floor and ty for taking the time for the meeting

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2011-04-25 19:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-25 18:55 [gentoo-hardened] Logs from meeting 2011-04-20 20:00 Magnus Granberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox