[gentoo-hardened] Log from meeting 2011-07-13 20:00 UTC

[gentoo-hardened] Log from meeting 2011-07-13 20:00 UTC

[Magnus Granberg]

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

Hi
Here is the log from the meeting we did have on 2011-07-13 20:00UTC

/Magnus (Zorry)

[-- Attachment #2: meeting-2011-07-13_20:00UTC --]
[-- Type: text/plain, Size: 22428 bytes --]

[22:17:46] <Zorry> 1.0 Hardened use flag
[22:18:11] <blueness> shall i start?
[22:18:15] <Zorry> do it
[22:18:37] <blueness> okay the issue of what the meaning of the "hardened" use flag came up
[22:18:56] <blueness> in the tree, the use flag is 90% meaning "hardened toolchain"
[22:19:06] <blueness> but there are places where it means "hardened kernel"
[22:19:19] <blueness> this ambiguity causes problem, so here's a solution
[22:19:30] <blueness> 1. the use flag means *only* hardened toolchain
[22:19:52] <blueness> 2. choosing hardened-sources over gentoo-sources means you've got a hardened kernel
[22:20:09] <blueness> 3. the profiles must cover both issues of the hardened toolchain and hardened kernel
[22:20:42] <blueness> 4. for packages, like syslog-ng and virtual/linux-sources, you either need to use a local flag, or no flag whichever is appropariate
[22:20:58] <blueness> eg for syslog-ng you need some flag that says you are using a hardened kernel
[22:21:10] <blueness> for virtual/linux-sources, you don't need any flag at all
[22:21:27] <blueness> although both use the "hardened" flag even though they have nothing to do with toolchain
[22:21:53] <blueness> the reason for this distinction is that you can have a vanilla toolchain with a pax hardened kernel
[22:22:38] <blueness> so, my plan would be to approach the maintainers of those packages and/or email gentoo-dev@ to alert them to our decision today about the meaning of the flag
[22:22:45] <blueness> and try to stay consistant in the tree
[22:22:49] <blueness> comments?
[22:23:12] <SwifT> for syslog, it's manly logrotate and default configuration, not?
[22:23:13] <gengor> so
[22:23:23] <blueness> hi gengor
[22:23:33] <Zorry> SwifT:  the config
[22:23:38] <blueness> SwifT, it has to do with modifications to syslog-ng.conf
[22:23:39] <gengor> the pie and hardened use flags were created and originally pertain to toolchain purposes only and not kernel.
[22:24:19] <gengor> firefox was the first to have problems with pax mprotect, and since no truly purposeful flag was available, we abused the hardened USE flag (as it would in fact represent at least the majority of the userbase)
[22:24:19] <blueness> right and that seems to be how it is mostly used, so we should just stamp out alternative uses
[22:24:26] <gengor> now more and more packages are having similar problems
[22:24:28] <gengor> so
[22:24:29] <idl0r> so we need at least one more flag
[22:24:40] <gengor> that leaves people who want to run just a hardened kernel or just a hardened toolchain
[22:24:48] <gengor> having to flip the flag on or off per-package
[22:24:50] <gengor> which is lame
[22:25:00] <gengor> so maybe there are better options
[22:25:04] <gengor> but at bare minimum
[22:25:31] <gengor> we should probably make a new USE flag like hardened_kernel, pax, pax_mprotect or something.
[22:25:39] <gengor> and we enable it by default in our profiles
[22:25:40] <blueness> do we ask people to use an alternative flag for situations like syslog-ng?
[22:25:47] <blueness> k
[22:25:52] <gengor> because we encourage people to use both the hardened toolchain and kernel
[22:25:53] <gengor> but
[22:26:03] <gengor> for those souls who want to run a hardened kernel on gentoo toolchain
[22:26:07] <gengor> they can now just enable this flag globally
[22:26:21] <gengor> and expect syslog-ng, firefox or whatever package has problems with hardened kernel next to "do the right thing"
[22:26:33] <gengor> or for those who want to run hardened toolchain w/o kernel
[22:26:38] <SwifT> but the next question then is when you consider a kernel hardened...
[22:26:39] <gengor> they just -flag globally
[22:26:43] <gengor> and they can set it and forget it
[22:27:01] <gengor> and not worry about setting stuff in package.use for each individual package or whatever package pops up next
[22:27:07] <SwifT> grsec (USE=grsec), pax (USE=pax), selinux (USE=selinux) ?
[22:27:25] <blueness> SwifT, i know, but the issue is really pax
[22:27:33] <gengor> SwifT: right.. so hence why I was sorta thinking we should maybe get a bit specific with the USE flag name rather than hardened_kernel
[22:27:35] <blueness> because pax is the only one that interacts with userland
[22:27:40] <gengor> like pax_mprotect or something
[22:27:58] <gengor> I'm all for better/even more fine grained solutions
[22:28:00] <idl0r> i'd tend to pax instead of pax_*
[22:28:17] <blueness> gengor, i agree with the name and for the reason of specificity, but i don't htink we need one for grsec or selinux ... at least not yet
[22:28:30] <blueness> so leave the door open to them in the future by choosing a specific name now
[22:28:33] <gengor> but if we have to not overcomplicate it (ex. w/ what makes up a hardened kernel, which you are right, is debatable) for the sake of solving the majority sake.
[22:29:27] <gengor> my 2c.  that's up to all of you to decide :)
[22:29:44] <blueness> okay shall i draft an email to gentoo-dev and propose this flag and give our rational, let's see where it goes?
[22:29:57] <Zorry> +1
[22:30:03] <blueness> also explain that hardened is for toolchain only
[22:30:27] <idl0r> e.g. for the pax eclass function we'd just need "pax? ( chpax )", it can change more than just mprotect
[22:30:50] <blueness> idl0r, true, there may be some cases where you need to turn off randmmap
[22:30:56] <blueness> i would go with just pax
[22:31:05] <Zorry> +1
[22:31:10] <quantumsummers|a> please just describe them well :)
[22:31:13] <gengor> current situation is: imagine you run hardened toolchain but not kernel, and one package after breaks w/ pax feature x.  each time this happens you have to a) identify the problem b) search around/fix it.
[22:31:22] <idl0r> so people with a hardened kernel but without hardened profile just enable pax and the eclass function will work properly
[22:31:28] <gengor> blueness: might want to make it something like pax_kernel or something
[22:31:39] <gengor> ("pax" seems to be a popular term/name)
[22:31:55] <blueness> gengor, yeah isn't it also an archive tool?
[22:31:57] <gengor> pax conference, k-pax, others
[22:32:11] -*- blueness thinks of the PAX ROMANA
[22:32:36] <quantumsummers|a> nice
[22:32:40] <onox> anyone ever heard of R_386_GOTOFF?
[22:32:40] <SwifT> yes, gentoo uses USE flags for roman history
[22:32:48] <quantumsummers|a> e tu blueness?
[22:32:48] <blueness> hehe
[22:32:55] <blueness> :)
[22:32:59] <Zorry> onox: later we have meeting
[22:33:14] <gengor> don't get me wrong, it still sucks to have to do this via USE flags.
[22:33:16] <blueness> okay i'll draft something and bounce it off Zorry and whoever else is here tomorrow
[22:33:31] <blueness> gengor, use flag bloat
[22:33:34] <gengor> the best solution is to patch the software to work standard & with whatever pax feature it is running afoul of.
[22:33:41] <gengor> that's traditionally how we fix these issues.
[22:33:50] <gengor> but I know sometimes that's difficult
[22:34:26] <gengor> blueness: yeah, and still tying a userland package to a particular kernel, etc.
[22:35:10] <blueness> okay, i don't have much more with one this issue, and i have a plan forward, so next agenda item?
[22:35:29] <Zorry> yep
[22:35:31] <blueness> s/one//
[22:35:37] <Zorry> 2.0 toolchain
[22:36:07] <gengor> oh and for the record I hate the idea of doing it based on what kernel *sources* are installed
[22:36:40] <gengor> (ie. checking on any specific provider of virtual/linux-source)
[22:37:01] <gengor> checking on the existence I mean
[22:37:08] <gengor> sorry, that is all.
[22:37:41] <Zorry> haven't done that mutch for the upstream patch for gcc
[22:37:47] <Zorry> gengor: np
[22:38:14] <Zorry> don't have mutch to say
[22:38:19] <Zorry> so any one
[22:38:43] <blueness> glibc-2.14 is coming and gcc-4.6/4.7 any news or concerns about them wrt hardneed?
[22:39:19] <Zorry> blueness: glibc-2.14 havent sen anything there
[22:39:53] <Zorry> and gcc-4.6 looks good
[22:39:58] <blueness> toolchain has a tracker on it, bug #370409
[22:40:02] <willikins> blueness: https://bugs.gentoo.org/370409 "[TRACKER] Packages failing to build with sys-libs/glibc-2.14"; Gentoo Linux, Ebuilds; CONF; flameeyes:toolchain
[22:40:14] <blueness> but a lot of things are broken
[22:40:14] <Zorry> and gcc-4.7 is still on stage1
[22:40:25] <blueness> yeah so there is still some time
[22:40:31] <Zorry> yes but not hardened things
[22:40:42] <Flameeyes> let's just say that glibc-2.14 is crap, shall we?
[22:40:51] <blueness> lol okay
[22:40:55] <Zorry> :)
[22:41:09] <blueness> every time a nge glibc comes out they change all the header structures
[22:41:18] <Flameeyes> blueness: I wish it was just that!
[22:41:21] <blueness> s/nge/new
[22:41:26] <Flameeyes> did you read my posts about the rpc stuff?
[22:41:27] <blueness> ah its worse
[22:41:35] <blueness> no, i heard they dropped it
[22:41:40] <SwifT> tl;dr ;p
[22:41:53] <Flameeyes> SwifT: coming from a doc guy it is sad :(
[22:42:03] <Flameeyes> blueness: http://blog.flameeyes.eu/2011/06/11/are-you-kidding-me-or-why-we-ll-wait-glibc-2-14-for-a-while
[22:42:04] <SwifT> was just kidding
[22:42:27] <Flameeyes> short version, glibc 2.14 dropped rpc support, and yp.. libtirpc was supposed to be used as a replacement for the rpc code but..
[22:42:35] <Flameeyes> a) it needed yp which was dropped as well, as I just said
[22:42:51] <Flameeyes> b) it still doesn't work with glibc-2.14 as it references symbols that are no longer available
[22:43:00] <Flameeyes> so the replacement is ... failing to work
[22:43:37] <blueness> k
[22:43:49] <blueness> i won't bother testing hardened + glibc-2.14 then
[22:44:03] <blueness> looks like there are still many other non-hardened issues to be worked out first
[22:44:12] <Zorry> yep
[22:45:13] <blueness> next?
[22:45:19] <Zorry> do any one else have some thing to say?
[22:45:31] <Zorry> k
[22:45:35] <Zorry> 3.0 Kernel
[22:45:43] <Zorry> blueness: ^^
[22:45:48] <gengor> 2.0 switch to eglibc.
[22:46:06] <gengor> :p
[22:46:28] <blueness> 1) stabilization of 2.6.39 is on hold because of a problem with parallel builds and a new gcc pax plugin
[22:47:05] <blueness> hopefully pipacs will see what's up with that, its a false circular dependency which fails when yo build with -jX where X > 1
[22:47:42] <blueness> 2) there were a few new options added by grsec team, like the kernel brute force and kernel stack leak options
[22:48:24] <blueness> these are all new and i think dangerous options which i have not forced on for any of the gentoo predefined hardenings, eg SERVER or WORKSTATION or VIRTUALIZATION
[22:48:45] <idl0r> can you briefly describe the new pax plugin plz? :D 1-2 sentences would be enough :P
[22:49:06] <blueness> i tested them and i have had mixed results, and Zorry says the stack leak causes lockup
[22:49:29] <blueness> idl0r, i haven't looked into what it does, but its a gcc plugin for 4.5 and above, i only tried to figure out the build system
[22:49:34] <Zorry> yes it do 
[22:50:28] <blueness> idl0r, i'm not even sure gentoo needs it because we get all the elf mangling we need for pax from patch 63 of our binutils package
[22:50:44] <blueness> so i'll read that code carefully after the meeting
[22:51:03] <idl0r> ok, thx :)
[22:52:18] -*- blueness is impatient and is reading it now
[22:52:28] <blueness> "gcc plugin to help implement various PaX features"
[22:54:08] <blueness> idl0r, it looks like a stub for future development, currently it just returns track the lowest stack pointer in some address space
[22:54:19] <blueness> s/returns/
[22:56:07] <blueness> sorry guys, let's move on, i don't want to extend the meeting unnecessarily
[22:56:23] <blueness> i'll try to work with pipacs to move ahead on 2.6.39
[22:57:04] <Zorry> k
[22:57:12] <Zorry> next ?
[22:57:56] <blueness> yes
[22:58:00] <Zorry> 3.0 Selinux  SwifT blueness
[22:58:12] <SwifT> k
[22:58:31] <SwifT> base policy -r18 is in the tree now (~arch) which includes openrc, syslog and psotgres fixes (in the policy)
[22:58:50] <SwifT> there are also a few package specific policies updated, like mozilla and nfs, but nothing major there
[22:59:12] <SwifT> i'm currently working on the policies for puppet (with the help of prometheanfire) and nginx, and haveged is also on the queue
[22:59:28] <SwifT> in the near future, i'll be doing the first tests with MCS (already have a few users asking for it)
[22:59:51] <SwifT> for the selinux packages (non-policy), I'm currently testing the latest userapp version
[23:00:07] <SwifT> it includes a patch from redhat for the vulnerability that was reported a few days ago
[23:00:25] -*- prometheanfire will be the guinea pig
[23:00:25] <SwifT> currently, we're not vulnerable, but when we enable MCS and want to introduce sandbox, we might be, so having the patch around is good
[23:01:02] <SwifT> i'm also checking if i can enable python3 support for the packages, but that's with mixed results
[23:01:17] <SwifT> might need to push that work immediately to upstream and hope they have better luck
[23:01:24] -*- SwifT isn't that good in that stuff :/
[23:01:41] <SwifT> vixie-cron is still not stabilized, I'll ping the cron herd again to see what's holding it up
[23:01:49] <blueness> SwifT, what sorts of problems are you hitting with python2 - python3 move?
[23:01:55] <SwifT> the stabilization of vixie-cron is needed to finalize our stabilization of the policies
[23:02:11] <SwifT> blueness: strings, bytes and unicode being used cross each other
[23:02:42] <blueness> SwifT, that's the usual kinds of problems i've seen, but i think there's stuff out there to fix it automatically
[23:02:46] <blueness> did you try?
[23:02:47] <SwifT> problem is that swig includes a few fixes around that, but these require that the code itself (c-code) is also altered (additional malloc and such are needed)
[23:03:01] <SwifT> blueness: yes, the 2to3 stuff... made it worse sadly (for libselinux-)
[23:03:44] <blueness> i can't say because only played with it on toy examples, nothing serious
[23:03:50] <SwifT> that's about it for selinux for me currently (apart from profiles, but that's for the profiles discussion I gather)
[23:03:59] <SwifT> we're never serious
[23:04:02] <SwifT> ;)
[23:05:08] <SwifT> oh yeah, blueness has been quite active in pushing the stuff from hardened-dev to the portage tree; thanks for that
[23:05:28] <blueness> yeah i've just been following your lead
[23:05:32] <SwifT> i'll send a mail with the bugs that can be closed :)
[23:05:36] <blueness> we need to get  you commit!
[23:06:07] <blueness> oh right, i did see a few i thought could be closed
[23:06:25] <SwifT> any others on selinux? feature requests? ;)
[23:06:34] <SwifT> (not that i don't already have a huge list)
[23:07:00] <blueness> SwifT, low on priority but there is that setroubleshoot that i put on the hardened-dev
[23:07:18] <SwifT> yeah, it pulled in too many graphical dependencies here to give it a first try :p
[23:07:19] <blueness> i tried to get it to work, but it requires some rpm module --- its python based
[23:07:41] <blueness> i'm not sure what we want to do with it, i used to use it in my selinux days
[23:07:53] <SwifT> never seen it before tbh
[23:08:06] <blueness> in fedora
[23:08:20] <blueness> well low priority
[23:08:27] <SwifT> i would let it in the overlay for now; I do not remember anyone explicitly asking for it and at least we have something to start from then
[23:08:41] -*- SwifT can work efficiently with his avc.log and vim
[23:08:47] <blueness> it was there in a bug report ... old bug report
[23:10:12] <blueness> next?
[23:10:24] <Zorry> yep
[23:10:30] <Zorry> 4.0 profiles
[23:10:58] <blueness> no major changes to the hardened profiles
[23:11:19] <blueness> there is a problem with a corner case, ppc64 with 32-bit userland
[23:11:21] <Zorry> we have added paxctl to package list
[23:11:28] <blueness> oh yeah!
[23:11:31] <blueness> thanks
[23:11:35] <Zorry> np :)
[23:11:56] <SwifT> i think, and blueness with me iirc, that we might want to introduce the new selinux profiles towards the public more (get more people to test them) before stabilization. Mail to gentoo-hardened, forum & blog requests, ...
[23:12:08] <blueness> anyhow HalcyOn is helping me with that corner case
[23:12:20] <blueness> right i was going to mention that
[23:12:29] <SwifT> ah sorry
[23:12:33] <blueness> no no problem
[23:13:01] <blueness> with the selinux profiles, i cleaned them up a bit
[23:13:21] <SwifT> but generally, the new profiles are positively received. I even had a user that did exactly the same thing a while back for him personally and was glad to see he could switch to an official profile again
[23:13:31] <blueness> SwifT, said we no longer need the pre 2.20xxx policies so i got ride of some of the masking for those
[23:14:06] <blueness> oh good to hear
[23:14:21] <Zorry> :)
[23:14:33] <blueness> all in all the selinux profiles are a lot cleaner and easier to work with
[23:15:05] <blueness> so as SwifT said, i'd like to ask people to start testing the new feature/selinux and eventually mark them stable
[23:15:19] <Zorry> +1
[23:15:36] <blueness> deprecation of the old ones is far into the future
[23:15:56] <blueness> i don't know what the policy is for marking profiles "stable" vs "dev" but i'll find out
[23:16:05] <prometheanfire> I;m going to start rolling out selinux to other hosts once the puppet fix is in mainline
[23:16:15] <blueness> nice
[23:16:24] <prometheanfire> so that will test some other software
[23:16:28] <SwifT> one question I do want to ask though is how to deal with updates on a profile. For instance, for MCS support, I'll most likely introduce a USE flag that I want to use.mask initially (since it's too experimental to start with)
[23:16:56] <blueness> SwifT, you just do it
[23:17:04] <blueness> you edit and commit
[23:17:16] <SwifT> I guess such fixes in the selinux profiles are easy and without (any) impact, but still... don't want to make a problem like with that USE="hardened" and eclass stuff recently :)
[23:17:34] -*- blueness wipes egg of his face
[23:17:45] <Zorry> :)
[23:17:51] <SwifT> hehe
[23:17:54] <blueness> SwifT, you can break things with the profiles, but the eclasses are more critical
[23:18:35] <blueness> the biggest thing to watch out for with hte profiles is changing the order of inheritance in the parent files
[23:18:57] <blueness> but masking/unmasking a flag, adding/removing a package is pretty safe
[23:19:07] <blueness> at least on the leaves
[23:19:28] <blueness> don't mess with base or arch profiles without discussing it
[23:19:59] <SwifT> certainly
[23:20:37] <blueness> well not exactly, i'll show you how selinux packages get masked and unmasked in base and then feature/selinux afterwards
[23:20:46] <blueness> but you may know that arleady
[23:21:00] <SwifT> yeah
[23:21:11] <SwifT> suckers don't support sec-policy/*
[23:21:19] <blueness> haha
[23:21:20] <SwifT> but I'm digressing ;)
[23:21:33] <blueness> okay i think we're done :P
[23:22:27] <Zorry> any one else?
[23:22:57] <Zorry> 5.0 docs
[23:23:23] <SwifT> me first?
[23:23:28] <Zorry> do it
[23:23:47] <SwifT> okay, for SELinux i've been starting to write module information, which is specific user information for particular SELinux policies (domains)
[23:24:02] <SwifT> I currently have such documentation for apache, bind, ldap and portage and am working on the information for ssh
[23:24:23] <SwifT> the module information informs the user about the SELinux booleans in use, how he might want to label files differently, etc.
[23:24:44] <SwifT> for instance, the portage one also talks on how to put portage tree on NFS (eh prometheanfire ?)
[23:25:08] <SwifT> if the ssh one is finished, I'll see if I can get klondike or so to push them to the cvs repo
[23:25:32] <prometheanfire> SwifT: I have access also methinks
[23:25:34] <SwifT> next to the module docuemntation, the SELinux handbook has seen a few changes as well, but all minor and all user command information
[23:25:51] <Zorry> SwifT: can push it to the cvs
[23:25:57] <SwifT> prometheanfire: cvs repo? nah, I mean gentoo's cvs repo where the proj drives are located
[23:26:07] <prometheanfire> oh, thought you meant docs
[23:26:08] <SwifT> well, i'll prod someone then ;)
[23:26:38] <SwifT> the other documentation that isn't pushed to cvs yet hasn't seen any updates, so I believe they are stable enough to be pushed as well
[23:26:46] <SwifT> that includes the selinux-development & selinux-policy documents
[23:26:59] <Zorry> k
[23:27:12] <SwifT> that's all I have to say on selinux docs now
[23:27:30] <Zorry> SwifT: ping me when the is done i fill push it on cvs
[23:27:37] <SwifT> Zorry: k, will do
[23:28:28] <prometheanfire> Ok, as far as virt docs are concerned, it seems like xen support for dom0 may be coming
[23:28:34] <prometheanfire> I'm going to be testing it tonight
[23:28:51] <Zorry> blueness: we should add some stuff about the (new use flag) when it is done
[23:29:01] <Zorry> prometheanfire: :)
[23:29:17] <prometheanfire> I'm also starting to have more time to do stuff now that I'm getting settled into the new job.location
[23:29:46] <prometheanfire> not much else to say otherwise, other then to expect me to be back a bit more
[23:29:55] <Zorry> nice
[23:30:26] <Zorry> some else have some thing ?
[23:30:29] <prometheanfire> can't do coding much, but I can at least test
[23:30:34] <prometheanfire> that's all for me
[23:30:56] <SwifT> yes, prometheanfire is helping well with testing and feeding information
[23:31:00] <Anarchy> What you having a meeting?
[23:31:03] <SwifT> and he's reactive :)
[23:31:13] <Zorry> Anarchy: yes
[23:31:43] <Zorry> okay next then
[23:31:49] <prometheanfire> not proactive :P
[23:32:41] <Zorry> 7.0 bugs
[23:32:53] <Zorry> any bugs to talk about ?
[23:33:31] <blueness> not really anything serious
[23:33:42] <Zorry> okay
[23:34:00] <blueness> upstream fixed one kernel bug in vanilla kernel that i submitted
[23:34:11] <SwifT> prometheanfire: didn't you create a bug for soemthing selinux related? can't see it yet in the selinux list
[23:34:14] <blueness> but its a rare case
[23:34:32] <prometheanfire> SwifT: no, the only thing was the nfs bug
[23:34:42] <blueness> ssh over ipsec is broken in all 2.9.39
[23:34:42] <blueness> s
[23:34:45] <SwifT> prometheanfire: k
[23:36:11] <Zorry> okay Open floor
[23:36:26] <Zorry> some one have some thing ?
[23:37:09] <Zorry> else meeting is done and ty for being on the meeting