From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ph6VL-000480-Qf for garchives@archives.gentoo.org; Sun, 23 Jan 2011 20:25:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67B4DE05BE; Sun, 23 Jan 2011 20:23:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EE65EE05BE for ; Sun, 23 Jan 2011 20:23:37 +0000 (UTC) Received: from laptop1.gw.ume.nu (ip1-67.bon.riksnet.se [77.110.8.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zorry) by smtp.gentoo.org (Postfix) with ESMTPSA id 1242D1B40BC; Sun, 23 Jan 2011 20:23:35 +0000 (UTC) From: Magnus Granberg Organization: Gentoo.org To: hardened-dev@gentoo.org, hardened-kernel@gentoo.org, hardened@gentoo.org, gentoo-hardened@lists.gentoo.org Subject: [gentoo-hardened] Meeting 2011-01-19 20:00 UTC log Date: Sun, 23 Jan 2011 21:23:23 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37-gentoo; KDE/4.5.5; x86_64; ; ) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_74IPNox1muivPAM" Message-Id: <201101232123.23424.zorry@gentoo.org> X-Archives-Salt: X-Archives-Hash: 756458f48edeacd1c71cfa223ed88262 --Boundary-00=_74IPNox1muivPAM Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Log from the meeting 2011-01-19 20:00 UTC Hardened at Gentoo.org Magnus Granberg (Zorry) --Boundary-00=_74IPNox1muivPAM Content-Type: text/x-log; charset="UTF-8"; name="meeting-2011-01-19_20:00UTC.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="meeting-2011-01-19_20:00UTC.log" [21:10:42] okay lets start the meeting [21:10:49] he said something about he wantint the nickname icarus and it being taken [21:10:53] ok Zorry [21:11:32] 1.0 Toolchain [21:12:05] have made a patchset for the gcc-4.6 that is in the overlay [21:12:34] and still no respons from vapier on the cryptsetup/glibc bug [21:12:59] Zorry: you mean the sighandler bug? [21:13:08] and i need to make the pch bug upstream [21:13:13] klondike: yes [21:13:25] :( [21:13:31] i only have a quick fix fo it now [21:13:49] glibc build system is mess :( [21:14:36] any one else have something ? [21:14:52] well me [21:15:00] but this is better spoken on docs time [21:15:07] k [21:15:27] next then? [21:16:16] yeah [21:16:30] but we need blueness for 2.0 and 3.0 [21:16:45] jump over 3.0 kernel and 2.0 virtuazition ? [21:17:18] I know some summary level stuff on it [21:17:31] virtualization specifically [21:17:41] okay [21:18:10] 2.0 virtual [21:18:17] prometheanfire: speek [21:19:04] http://goo.gl/cnA1J is a summary of where we stand on kvm as both guest and host [21:19:32] specifically a diference on what options are able to be enabled on amd vs intel processors [21:20:36] ATM as far as I know XEN is not supported by the hardened project [21:21:10] I tested VMware and given its binary nature linking against a hardened system leads to system instability [21:21:12] well I have some docs I was referred to by blueness [21:23:01] for Virtualbox (which seems to be what blueness is pushing for as a desktop virtualization platform) there is some work and patching needed to get it to work with our gcc [21:23:05] HI [21:23:07] that's all I have [21:23:20] prometheanfire: okay [21:23:22] -*- quantumsummers|a will read back (sorry is late) [21:23:23] prometheanfire: just for the record on XEN [21:23:26] http://bugs.gentoo.org/show_bug.cgi?id=279795 [21:23:32] http://forums.grsecurity.net/viewtopic.php?f=1&t=2063&start=45 [21:23:39] http://forums.gentoo.org/viewtopic-p-6388313.html#6388313 [21:24:21] klondike: thanks [21:24:40] blueness: pointed me to them just didn't have enough time to read them [21:25:06] looks like xen is possible, just not well tested [21:26:52] next then ? 4.0 SELinux [21:27:20] klondike: You have anything you want to jump in with? [21:27:35] not me [21:27:43] SwifT? [21:27:44] maybe SwifT has? [21:27:53] well, about the document perhaps? [21:28:02] -*- klondike still has to read the doc :( [21:28:04] Do you want to do that here or wait for docs? [21:28:21] it can wait for the docs topic [21:28:24] 'k [21:28:26] Then here it is [21:28:43] We've put up a number of new policies in the hardened overlay [21:28:50] SwifT: has added a boatload of patches [21:29:11] Upshot is, we stand a fair chance of being able to boot and run a SELinux Gentoo Hardened system now [21:29:25] There's support for libvirt-based stuff in the policy [21:29:32] but don't have xen or vmware yet [21:29:43] (there are dependencies there that still have to be addressed) [21:29:58] Working on a patch for openrc to resolve a couple of issues there. [21:30:15] true, and you're not able to run kvm guests without libvirtd in the current one (i have a few of these patches pending though) [21:30:53] SwifT: you are saying that there is not a ruleset for running kvm manually? [21:30:54] SwifT has also added a bunch of patches that I think make desktop SELinux on Gentoo almost a reality now. [21:31:16] prometheanfire: not in strict, no [21:31:46] Still looking at a bug with policy and vixie-cron [21:31:55] I think that about covers it? [21:32:14] on the matter of patches, like gizmo said, there will most likely be a lot more coming; I'm not committing them yet as they will enlarge the files/ folder too much [21:32:40] once I have a stable set, I'll put them online in a tarball somewhere and see to use that one (like we do with hardened-sources, for instance) [21:32:55] SwifT: I've got a place we can host the tarball [21:32:58] (of course, after having gizmo take a look at that approach :) [21:33:03] cool [21:33:23] also, you'll see from the mailinglist discussion that we're touching some important grounds on policies for the future [21:33:44] Ah, yes, SwifT has been asking some good questions there. [21:33:46] if we can agree on an approach for policies, we should be able to fire off :) [21:35:07] also, like gizmo, I'll see if I can track upstream (reference policy) as much as I can; however, they might have a different approach on policy rules [21:35:29] Keeping synchronized with upstream is going to be a bit of work, but I think it will be worth it. [21:35:47] 'k, is that it? [21:35:55] think so [21:36:00] *clap clap clap clap clap* I think I speak for most of us saying "Good job guys" [21:36:00] clear then [21:36:10] hi guys, sorry i'm late [21:36:19] is the meeting over? [21:36:23] slow doggie blueness? [21:36:24] blueness: no [21:36:27] k [21:36:28] blueness: no, but now you have to bring the pizza's [21:36:32] We ended 5 minutes ago [21:36:36] gizmo: SwifT kepp up the work [21:36:58] Zorry, tell me when you want to give my report [21:36:58] Thanks guys. SwifT's been doing a lot of the heavy lifting this last couple weeks, I think. [21:37:26] let's wait on the appraisals until we have more than 3 people testing the things out :) [21:37:42] SwifT: you need testers? [21:38:05] I'm tempted to test if the policies are there [21:38:08] klondike: yes, and they should already take frequent backups of their systems :p [21:38:28] SwifT: I may be able to do some tests on a Direct connect hub [21:38:53] klondike: let's talk after the meeting about that then [21:39:06] ok [21:39:49] is the 4.0 SELinux done ? [21:40:17] Zorry: yes [21:40:53] okay back to 2.0 virtula and 3.0 kernel [21:41:00] blueness: ^^ [21:41:03] k [21:41:29] regarding virtualization, i've explored lots of options for virt on hardened and found what i think is the best solution [21:41:40] for desktop systems, its VirtualBox [21:41:58] there are a few issues there: 1) i still haven't got the built system figured out so that it builds nopie [21:42:18] so for now, you have to manually swithc profiles, but i'll get it eventually [21:42:35] 2) there is a some issue with virtualbox 4 causing kernel panics [21:42:43] so virtualbox 3 on hardened is good [21:43:06] for server systems, kvm is good, i've tested now on intel and amd with acceleration [21:43:20] what is not so good is xen, so i don't think i will pursue that [21:43:37] there is however, one sacrifice that has to be made with virt on hardened [21:43:57] whether it is virtualbox or kvm, you have to turn off KERNEXEC and UDEREF [21:44:19] these are good hardening measures, but they get you into trouble under lots of circumstance [21:44:22] so ..... [21:44:34] b, [21:44:42] i'm going to create another security level in addition to SERVER, SERVER NO RBAC, etc [21:44:56] it will be VIRTUALIZATION HOST [21:45:16] and the kernel HELP will make clear what is sacrificed with this option [21:45:38] i haven't done this yet, but please think about this and comment [21:45:44] blueness: the kernexec and uderef issues trigger on both AMD and intel with KVM? [21:45:50] yes [21:45:56] Odd [21:46:05] remember he is talking about the host part :-) [21:46:13] yeah, had to deactivate those as well for kvm/intel here [21:46:13] Yeah [21:46:31] klondike, there are some exceptions, but if you want it to work in all situations, you pretty much have to sacrifice them [21:46:36] But I don't recall problems with kernexec before, maybe is on new modules? [21:46:44] kvm/intel uderef has to be disabled on guest if I remember right [21:46:54] thismay not continue forever, pageexec and I have a pug upstream with vbox about KERNEXEC [21:47:14] guys, got a job interview in about 20 minutes, gotta bail [21:47:21] gizmo: good luck [21:47:32] gizmo: good luck [21:47:40] prometheanfire, that may be the case, but for the host for sure these options are a problem in both kvm and vbox [21:47:50] blueness: yes [21:47:56] gizmo: the team is with you Good Luck [21:48:19] anyone object to adding the VIRTUALIZATION HOST option to grsec security levels? [21:48:36] blueness: me [21:48:37] or see a problem with it? [21:48:41] do it [21:49:09] blueness: maybe you should warn on that it may be less secure on the host type itself [21:49:17] okay will it won't happen over night, but if you email me later with comments [21:49:28] klondike, it will have to be in the kernel HELP [21:49:39] blueness: just switch to VIRTUALIZATION HOST (may be insecure) [21:49:49] Then explain why in the help [21:49:56] yeah, something like that [21:50:23] okay that's the virtualization, I can move on to kernel [21:50:30] k [21:50:53] kernel update ... upstream is maintaining .32 as promised and has just recently dropped .36 for .37 [21:50:59] i'll follow too [21:51:11] nice :) [21:51:32] (actually i'm running .37 now, it'll be on the tree tomorrow) [21:51:35] if all is good [21:52:05] i'm going to drop 2.6.28 soon, i think its now very old [21:52:27] feel free drop it [21:52:31] ok blueness I'll be around in case something bad happens [21:52:33] there was on bug that came in recently about it, and pageexec wasn't too interested because its over a year old [21:52:36] blueness: I'm on 2.6.32 on the recalcitrant vendor driver, so no fights from me. [21:52:45] blueness: 2.6.36 elsewhere, which has been awesome. [21:52:50] yeah its time for it to go [21:53:17] as soon as i stabilize the last .32 and .36, i'll drop .28 [21:53:19] blueness: I think it was solar that wanted to keep .28 around for some reason [21:53:24] and yes, .36 has been execellent [21:53:33] quantumsummers_, yes, stability [21:53:38] maybe infra related, perhaps [21:53:40] it was tried and true [21:53:48] quantumsummers_, i can bounce it off of them [21:54:06] i'll do that right after the meeting, maybe email infra@ [21:54:10] yes, a good kernel. I still have a box or two running it, but that is no biggie [21:54:31] okay one last thing about the kernel [21:54:33] blueness: cc solar just in case [21:54:38] k [21:54:53] last point about the kernel, related to the VIRTUALIZATION HOST option [21:55:12] i'm thinking we might now have too many security level options, but i'm open to how people feel [21:55:23] I don [21:55:30] do we really need SERVER and SERVER NO RBAC? [21:55:36] I don't think there are too many [21:55:45] and WORKSTATION and WORKSTATION NO RBAC? [21:55:56] quantumsummers_, okay (less work for me) [21:55:56] its nice to have the rbac/no-rbac options IMO [21:56:00] k [21:56:05] blueness: the only diff is having RBAC on or off? [21:56:24] klondike, yeah thats' the only diff and we can leave that option open for user selection [21:56:35] with each setting you have 3 possibilities [21:56:43] forced on [21:56:45] forced off [21:56:56] off but can be turned on by user [21:57:02] Maybe we could make the options RBAC free and let the user choose? [21:57:19] blueness: I run server no rbac on my servers atm, but only because of managability [21:57:21] that's what i was thinking, but if people like it i have no strong feelign [21:57:30] -*- klondike never understoo why having a preset with it on and other with it off [21:57:36] klondike: nor I [21:57:40] convenience [21:57:53] chooseing SERVER under my scheme would not force RBAC on or off, the user would choose independantly [21:58:12] seems reasonable, what would the default be? [21:58:22] blueness: I like that [21:58:46] quantumsummers_, convenience is right, so its not a hard issue, i just thought i'd bring it up because if i'm messing with that code for VIRTUALIZATION HOST, i was thinkng "should i clean it up" [21:58:56] quantumsummers_, the default would be off [21:59:09] off but option to turn it on [21:59:20] WORKSTATION/SERVER: on select, submenu: select RBAC on/off ? [21:59:30] yes [21:59:31] seems reasonable, but its a departure from the status quo [21:59:49] which is not a bad thing [21:59:54] I vote for doing the change on .37! [22:00:24] klondike, too late now but whenever its done, if its done, i'll just make sure all lists know [22:00:34] sounds good [22:00:36] blueness: mind delaying .37 a day and adding that? [22:00:36] anyhow think about it [22:00:56] klondike, no i don't want to rush add it [22:01:11] Ok blueness take it easy then [22:01:15] ^^^ bad grammar ^^^ [22:01:37] quantumsummers_ has a point, you don't want to break from the status quo and possible confuse people [22:01:43] Sorry about my grammar [22:01:56] this is the first time i've mentioned it publicly [22:01:56] blueness: you might mention that to infra, as they are important consumers of hardened-sources [22:02:08] (klondike, my grammar was bad, not yours :) [22:02:17] quantumsummers_, yeah both isse then [22:02:21] +1 [22:02:45] okay i'm done with my report sorry for delaying the meeting [22:03:24] np [22:03:42] nah it wasn't that much [22:04:13] okay 5.0 Profiles [22:04:58] the switch form /10.0 to / seems to have works fine so far [22:05:42] have added -jit as defult for the hardened profile [22:06:30] Zorry: unless some other profile inherited by hardened profile enabled it, it has no influence [22:07:09] still testing to disable the pic use flag for the amd64 arch as default [22:07:24] Tommy[D]: yes i know [22:08:02] and a quick grep tells me, that no profile enables it by default [22:08:08] Zorry: why don't use.mask the flag? [22:08:36] klondike: some may not have mptotect on [22:08:52] Zorry: those can just use.unmask it [22:09:02] -*- klondike checks the faqw [22:10:28] coast clear on that I thought I wrote on unmasking [22:10:54] blueness: do you have something to say? [22:11:05] or any one else? [22:11:16] nothing more [22:11:22] nope [22:12:04] okey next 6.0 docs [22:12:12] Ok [22:12:31] 6.1 approvent of the hardenedFAQ [22:12:39] have all look at it ? [22:12:51] I sure did :P [22:13:21] i looked at an earlier version and made some minor recommendatioins to klondike [22:13:37] blueness: those were applied IIRC [22:13:51] yeah i think so [22:14:30] perhaps a typo, there's "wether" somewhere [22:14:33] I added some minor aclarations asked by Aleister on last version too [22:14:43] a wether's a castrated sheep [22:14:44] i couldn't at that time think of any more questions to ask, but we can grow it as people think of things [22:15:17] SwifT: whether then? [22:15:34] klondike: yup [22:15:46] other than that, no obvious flaws found here [22:17:24] Ok [22:17:36] I'll have that fixed when the meeting ends [22:17:46] (having some git trouble now :( ) [22:18:43] can I shime in on the selinux doc? [22:19:25] yes go ahead [22:19:32] klondike: we fix the needed stuff after meeting and i will commit it tomorrow [22:19:37] that okay ? [22:19:42] ok [22:19:43] well, the selinux handbook update in the git repository should be usable. I'm not going to make changes myself most likely (I don't seem to hit anything, even with reinstallations in kvm guests) [22:20:04] there's one thing I'm not happy about and that's the installation instructions themselves [22:20:22] there's a part on "manual system changes" that might be needed to boot in SELInux enforcing on a hardened system [22:20:36] these should be fixed in ebuilds/policies rather than documentation [22:21:01] yet I have not been able to resolve them in the sec-policy/selinux-* packages themselves :( [22:21:43] one is to support LVM at boot-time, one is for dhcpcd and one is an issue a user came across in this chat channel a few days back [22:22:17] I know gizmo's working on dhcp policies as well, so he might be able to fix that manual approach, but that still leaves the LVM and that other issue (net-tools hardlinking some binaries) [22:22:42] if you're interested, http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/selinux/hb-using-install.html;hb=HEAD -> look for "Manual System Changes" [22:23:13] but other than that, like I said, refollowing all documented steps in a KVM guests seems to work well [22:23:40] as you might have noticed, I also put up a PDF version of the book because the HTML previews for books are difficult to navigate [22:24:10] PeBenito has made a few good comments so far; new ones are always welcome [22:24:40] one thing I'll now try to do is, when I make a change, first commit the change (in the sources), then commit the previews [22:24:45] makes it easier to review changes :) [22:24:58] that's all I have to say about the selinux doc [22:25:33] ok [22:26:02] prometheanfire: aside from the research you and blueness did any progress on the virt doc? [22:26:32] klondike, i didn't add anything [22:27:38] prometheanfire: is AFK :( [22:27:45] well for the rest of docs [22:28:05] klondike: did you have some thing for the gcc ? [22:28:07] sorry, phone [22:28:15] as aid, the FAQ has improved a lot, up to the point that I think we can refer newbies to it [22:28:38] klondike: I have not updated the docs [22:28:47] ok prometheanfire :D [22:28:51] Take your time [22:28:57] klondike: you bet I am [22:29:07] on the gcc docs as said by Zorry we did some small progress [22:29:29] I have uploaded a txt summary of my notes for now [22:29:40] k [22:29:44] and when we both have time I hope we improve this a lot [22:29:53] hope to :) [22:30:37] the good side is that if something bad were to happen to Zorry now a new dev taking the challenge should be able to understand what is happening [22:30:48] but we didn't spoke of the inners yet :( [22:31:11] but you have clue :) [22:31:51] we also added a doc on TPE as requested by blueness I think the amount of tests showed is enough to show how it works if aanybody has suggestions please tell as this doc goes along with the FAQ [22:32:46] And I think that's all, I just want to recommend you to refer newbies to the FAQ for the time being until we update the rest of docs [22:32:57] Anybody has something to add to this? [22:33:08] klondike, yeah that's good stuff [22:33:22] 1 sec, i'll get the bug it should address [22:33:36] http://bugs.gentoo.org/show_bug.cgi?id=216908 [22:33:52] !bug 216908 [22:33:56] klondike: https://bugs.gentoo.org/216908 "TPE Invert GID misbehavior"; Gentoo Linux, Hardened; NEW; decoder@own-hero.net:hardened-kernel@g.o [22:34:07] the TPE and TPE INVERT cause some confusion [22:34:23] oh and the TPE_ALL [22:34:41] Ok will put it as a blocker on the docs tracker and comment on it :D [22:34:56] so there should be 4 cases to look at, TPE_INVERT on/off TPE_ALL on/off [22:35:06] 5 [22:35:09] and no TPE [22:35:13] lol yeah [22:35:29] all of them were taken into account [22:35:37] that's the default all should know about, but sure put it in for comparison [22:35:41] with an assorted set of permissions [22:36:06] i think once those docs go in, i'll close that bug and refer readers to your do [22:36:15] so we wait for the tpe doc to be ready befor we commit the hardenedfaq? [22:36:36] klondike, is the tpe doc ready? [22:36:40] Zorry: it is ready unless blueness has any objections [22:37:04] i didn't see any problems, but i'll look right now [22:38:02] any one? else i will commit the faq and the tpe doc tommorow [22:38:45] Zorry, klondike i'll read over the tpe now and bug you if there is a problem, else commit [22:39:08] Ok [22:39:12] i'm more worried about errors than completeness, we can always add more later, but we should make sure there are no mistakes [22:39:28] I'd like to have another volunteer proof reader for it :/ [22:39:33] blueness: okay [22:39:42] Aleister: you could spend 5 to 10 minutes? [22:39:58] klondike: sure you just me a link :-) [22:40:08] Aleister: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/grsec-tpe.html;h=a6b31077780570799a1fd355eba5f06e9ceaa00f;hb=HEAD [22:40:30] the only critique of the tpe was how to more concisely present the test cases, but since i don't have a better answer, we'll stick to the tables as presented for now [22:40:44] k [22:40:54] blueness: I think the summary states things quite well [22:41:07] maybe we could refer people to it for starters [22:41:25] klondike: You can also enable a weaker restriction which will prevent race conditions on code executed by non root users as normal users will only be able to run executables either on their own not group nor world writable directories or root directories writable only by root. [22:41:30] klondike: that's one sentence? [22:41:33] klondike, it does its just long, not sure how else to present it [22:41:58] SwifT: I'm afraid yes [22:42:16] klondike: I'm failing to parse from "not group" onwards [22:42:51] klondike: a little rephrazing might be useful there :) [22:43:04] klondike, i'll email you a couple of changes i see in a minute [22:44:14] SwifT: [22:44:15] You can also enable a weaker restriction which will prevent race [22:44:17] conditions on code executed by non root users as normal users will only be able [22:44:18] to run executables on (not group writable and not world writable) directories [22:44:20] owned by them and on root directories writable only by the root user. [22:44:21] better? [22:45:29] aside from the TPE discussion nothing more to say :D [22:45:33] klondike: perhaps use "will only be able to run executables on directories only writeable by the owner" ? [22:45:35] TPE is a protection... what does TPE stands for? [22:45:53] Trusted Path Execution I think [22:45:58] trusted path execution [22:46:09] klondike, htat's what i want to add in the first paragraph [22:46:16] then say that and put (TPE) afterwards :-) [22:46:40] klondike: or "on directories that are only writeable by the root user, or on directories that only they have write access to" [22:46:57] if I read it correctly, that is :) [22:48:20] klondike, Aleister's right, that's the only thing really missing is a definition of what it is and how it works. i'll email you a suggetion [22:49:18] http://dpaste.com/333748/ [22:49:25] There I fixed it [22:50:22] well let's move on to the next point, shall we? [22:51:28] yes 7.0 Bugs [22:51:54] any bugs that need some talks? [22:52:59] okay meeting done? [22:53:47] meeting open for users --Boundary-00=_74IPNox1muivPAM--