Hi
Here is the log from the meeting we did have on 2011-07-13 20:00UTC
/Magnus (Zorry)
[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
