söndag 15 juni 2014 23.33.18 skrev du: > Hi > Here is one from a old meeting and one from a days ago. > There was no meeting on may. > /Magnus The logs.
[23:13:45] <Zorry> 1.0 Toolchain [23:14:03] <blueness> here [23:14:09] <lejonet> \o/ [23:14:14] <Zorry> gcc 4.9.0 is out so i fixing the patches [23:14:39] <Zorry> it will have -fstack-protector-strong as default on [23:14:57] <Zorry> and hardened will have -all [23:15:42] <prometheanfire> Zorry: sure, sec [23:16:21] <prometheanfire> blueness: oh, nvm [23:16:22] <Zorry> so next gcc version is on stage1 sone so time to upstream the patches again [23:16:32] <blueness> prometheanfire, did you just call me? [23:16:36] <prometheanfire> ya [23:16:37] <blueness> k [23:17:08] <blueness> Zorry, where the patch rejected for 4.8? [23:17:36] <Zorry> haven't got gcc 4.9.0 to build yet with gentoo patchset [23:17:54] <Zorry> blueness: no intrest to add them :( [23:18:06] <blueness> k [23:19:17] <Zorry> so i hope we will have gcc 4.9.0 in the tree sone [23:19:57] <klondike> cool [23:20:30] <Zorry> that is all from me [23:20:35] <klondike> on my phone again (sadly my laptop died completely) [23:20:37] <Zorry> blueness: ? [23:20:54] <blueness> only a small point about uclibc [23:21:06] <blueness> amd64 and i686 have been stable for a long time now [23:21:24] <blueness> so we are going to distribute them via /release instead of /experimental [23:21:30] <blueness> i think armv7a might be next [23:21:35] <blueness> but not mips [23:21:42] <blueness> another point about musl [23:21:51] <blueness> i've succeeded in getting amd64-musl hardened [23:22:21] <blueness> i'm working on i686-musl hardened, but gcc spits out a silly symbol: __stack_chk_fail_local which is not in mustl [23:22:22] <blueness> musl [23:22:42] <blueness> so i need to write a wrapper function but that will then mean i686-musl will be hardened too [23:23:03] <blueness> so i'm pushing hardening out to the various embedded libcs [23:23:08] <klondike> blueness you could check the glib one [23:23:13] <Zorry> that symb i hidden and [23:23:15] <klondike> glibc [23:23:24] <blueness> Zorry, i know but gcc emits it anyhow [23:23:39] <klondike> libgcc maybe? [23:23:51] <blueness> and stage1 gcc fails on i686 because its looking for that sym [23:24:17] <blueness> alpine linux hits the same problem [23:24:27] <klondike> because it's needed for ssp even on non hardened gcc [23:24:54] <blueness> i don't get why this happens on i686 but not amd64 [23:24:58] <blueness> Zorry, any clue? [23:25:48] <klondike> blueness is it configure complaining? [23:25:52] <blueness> anyhow, i now how to proceed on this one, Zorry maybe we can talk later [23:25:54] <blueness> klondike, no [23:26:00] <blueness> link error at libgomp [23:26:05] <klondike> ugh [23:26:08] <blueness> yep [23:26:18] <blueness> it *expects* the symbol to be visible [23:26:21] <klondike> disable openmp then [23:26:23] <blueness> but it is not [23:26:30] <blueness> klondike, no, its a simple patch [23:26:41] *** Mode #gentoo-hardened +v pipacs by Zorry [23:26:49] <blueness> i don't want to compromise on openmp [23:26:55] <blueness> hi pipacs [23:26:59] <blueness> okay that's all from me [23:27:04] <pipacs> anything i missed? ;) [23:27:06] <blueness> and SwifT thanks for applying that patch [23:27:15] <SwifT> no problem [23:27:17] <blueness> pipacs, nothing really, we're talking hardened toolchain stuff [23:27:32] <pipacs> when's gcc 4.9 coming? [23:27:37] <blueness> its out [23:27:43] <pipacs> i know, i mean gentoo ;P [23:27:50] <blueness> lol soon ;) [23:27:58] <Zorry> pipacs: when the gentoo patchset get out [23:28:00] <pipacs> what's the plan on ssp-strong? [23:28:10] <Zorry> pipacs: enable by default [23:28:23] -*- blueness is having a deja vu experience! [23:28:24] <pipacs> on hardened only? or even for normal profiles? [23:28:32] <blueness> normal [23:28:33] <Zorry> on normal [23:28:37] <pipacs> ouch ;P [23:28:44] <pipacs> did anyone test the result? [23:28:46] <blueness> hardened will have --fstack-protector-all [23:28:52] <blueness> pipacs, whats' the concern? [23:28:59] <pipacs> speed [23:29:06] <blueness> ah [23:29:28] <pipacs> -all wasn't exactly a winner historically and i haven't seen many raw numbers for -strong [23:29:49] <blueness> -all is overkill [23:29:51] <Zorry> pipacs: should be something in the middel [23:29:52] <pipacs> but if USE=nossp turns it off, i won't complain :P [23:30:09] <pipacs> zorry yes that's the marketing, but that doesn't make up for actual numbers [23:30:44] <klondike> I suppose it has heuristics with higher likelihood to say yes [23:31:01] <pipacs> yes, it increases instrumentation coverage [23:31:13] <pipacs> but that has a performance impact that noone talks about in actual numbers [23:32:12] <pipacs> for that matter there isn't much data about how much bigger the coverage is for various sw [23:32:12] <Zorry> think even Ubuntu will have that as default [23:32:28] <blueness> for the records, here are the "extra" that are added by -strong over vanilla -fstack-protector -> https://docs.google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/edit?hl=en_US [23:32:55] <pipacs> yes i know that, i even read the gcc code [23:33:02] <pipacs> what's missing is real life data ;) [23:33:07] <blueness> pipacs, do you mean build time performance, runtime performance, or both [23:33:21] <pipacs> runtime only [23:33:25] <pipacs> build time is pretty much unaffected [23:33:26] <klondike> I suppose he cares about runtime [23:34:08] <Zorry> pipacs: if it get to big performance impact it will move to vanilla -fstack-protetor [23:34:28] <klondike> you could try adding profiling and composing of it's a strong matter [23:34:56] <klondike> comparing damned phone [23:35:23] <pipacs> i'm sure some apps have test suites that can also be used to compare performance [23:35:33] <blueness> pipacs, do you think -strong might even have a greater perf impact than -all because of the added intelligence to check for the exceptions? [23:35:34] <pipacs> or since 3.14 even the kernel can be benchmarked [23:35:50] <pipacs> blueness, not at all, strong is strictly less impact than -all [23:36:13] <blueness> oh right, i just realized that, the intelligence is at compile time [23:36:13] <pipacs> that checking desribed in the doc is at compile time [23:36:15] <Dwokfur> isn't strong is the way to go? [23:36:26] <pipacs> some selector code that decides what functions to instrument [23:36:34] <blueness> right [23:36:35] <prometheanfire> wht type of hit is it, has anyone done/published benchmarks with/without [23:36:48] <pipacs> prometheanfire, that's my question exactly [23:36:57] <pipacs> too many people are jumping on -strong without data [23:37:11] <prometheanfire> because if it's bad we should know, and if it's not bad we should know [23:37:17] <Zorry> fedora should have done some test i think there code [23:37:19] <prometheanfire> so someone do that [23:37:20] <prometheanfire> notit [23:37:34] <pipacs> if you find anything on the web, send it to the list ;) [23:38:09] <prometheanfire> ofc [23:39:02] <Zorry> any thing more or next? [23:39:18] <prometheanfire> n [23:39:39] <Zorry> 2.0 Kernel and Grsec/PaX [23:39:56] <blueness> nothing much to report here [23:40:07] <blueness> install-xattr is still not full keyworded [23:40:16] <blueness> and there is no patch to get it into portage [23:40:27] <klondike> depending on how busy I'm this summer I'll try to schedule done testing if I can [23:40:44] <blueness> with zmedico gone missing, i've pinged dol-sen but he keeps deferring me to arfrever [23:40:47] <blueness> and i didn't get far [23:40:53] <blueness> we're so close but still not there [23:41:10] <prometheanfire> arf would be who I reccommend on the python team [23:41:12] <klondike> arfrever? [23:41:16] <prometheanfire> ya [23:41:27] <prometheanfire> Arfrever [23:41:35] <Arfrever> blueness: I heard about a new problem (whose existence is not yet confirmed/rejected by me): #506666 [23:41:47] <klondike> blueness just ping him, if he has time he'll do it :-) [23:42:27] <prometheanfire> bug 506666 [23:42:29] <willikins> prometheanfire: https://bugs.gentoo.org/506666 "Linux >=3.14: Extended attributes cannot be set by non-root users"; Gentoo Linux, Core system; CONF; klausman:kernel [23:42:36] <prometheanfire> really? wow [23:42:39] <blueness> uh oh! [23:43:02] <klondike> quotas in action? [23:43:27] <pipacs> well, depends on which xattr namespace [23:43:29] <blueness> that's a problem, i'll work with kernel team to try to get past that [23:43:30] <pipacs> did he specify what failed? [23:43:51] <klondike> user namespace should bee allowed [23:44:29] <blueness> i can come up with a patch if its a new upstream "feature" [23:45:03] <Arfrever> pipacs: ACL is stored in system.posix_acl_access attribute. [23:45:32] <klondike> I'd make it a tunable [23:45:59] <klondike> arfrever blueness says ping :-P [23:46:31] <blueness> huh? [23:46:43] <pipacs> sure, the system namespace is privileged [23:46:48] <pipacs> but does gentoo make use of it? [23:47:06] <blueness> pipacs, we do use acls [23:47:29] <pipacs> what for? ;) [23:47:35] <klondike> yes when acl use I'd enabled [23:47:48] <blueness> pipacs, it depends on the package [23:47:51] <pipacs> to deprivilege ping and stuff? [23:48:13] <blueness> and we also use caps, see fcaps.eclass [23:48:24] <Dwokfur> what if the attributes would be stored in an ELF header? :-) [23:48:31] <blueness> Dwokfur, NO!!!! [23:48:53] <Dwokfur> I hope you noticed the smiley... :-) [23:49:16] <klondike> I'm in for that, would you like cyanide flavoured elfs too? [23:49:33] <Arfrever> With Linux 3.13, non-root user can change system.posix_acl_access, but not other attributes in system namespace. [23:49:38] <blueness> Dwokfur, i did [23:50:00] <Dwokfur> klondike: I prefer dwarfs over elfs... [23:50:31] <blueness> Zorry, i have to go soon, i have no more for the meeting [23:51:01] <klondike> see you blueness take care [23:51:42] <Zorry> blueness: okay [23:52:43] <Zorry> next? [23:52:58] <SwifT> y [23:53:22] <Zorry> 3.0 Selinux [23:53:41] <SwifT> ok; r1 policies are stable, r2 is in the tree (~arched) [23:53:53] <SwifT> I added USE support in the policie to selectively enable support [23:54:14] <SwifT> in the past, domains like mozilla_t had all possible privileges in them for, say, ALSA stuf [23:54:26] <SwifT> now, with USE="-alsa", the ALSA support in the policy is no longer built in [23:54:28] <prometheanfire> using r2 on my systems, seems good so far [23:54:51] <SwifT> more info on USE flags for policies @ http://blog.siphos.be/2014/03/proof-of-concept-for-use-enabled-policies/ [23:55:07] <SwifT> it's "just" implemented for alsa right now, but I'm going to extend that soon [23:55:33] <SwifT> and yes, systemd and selinux on gentoo don't play nice together [23:55:34] <klondike> how is that different from Booleans? [23:55:52] <SwifT> booleans can't always be enabled [23:56:00] <SwifT> some policy code needs to be at build-time [23:56:01] <klondike> I see [23:56:27] <SwifT> on systemd and selinux, it's all about waiting for upstream to support it - or finding people willing to do the heavy lifting on gentoo for that [23:56:32] <SwifT> (I don't have systemd systems/VMs) [23:56:43] <SwifT> that's it for selinux [23:57:11] <Zorry> 4.0 System Integrity [23:57:32] <SwifT> nothing to say there sadly [23:57:46] <SwifT> IMA/EVM is still working, but no advances otherwise ;) [23:57:57] <klondike> I got tpm systems to play with if anybody wants to test something [23:59:19] <Zorry> next? [23:59:26] <SwifT> yup [23:59:33] <Zorry> 5.0 Profiles [23:59:49] <Zorry> nothing from me there [00:00:05] <Zorry> next then [00:00:37] <Zorry> 6.0 Docs [00:00:51] <SwifT> nothing hardened related [00:01:19] <klondike> nothing [00:01:27] <Zorry> next [00:01:33] <Zorry> 7.0 Bugs [00:01:43] <klondike> Will be on forced leave [00:01:56] <Zorry> !bug 503174 [00:01:57] <willikins> Zorry: https://bugs.gentoo.org/503174 "udev missing from sysinit runlevel in hardened 20140227"; Gentoo Release Media, Hardened; CONF; gentoo-bugs:release [00:02:00] <klondike> until I can replace my laptop [00:02:16] <Zorry> will be fixed when the affected packages get stable [00:02:50] <klondike> no [00:03:02] <klondike> I'm sure that was fixed on last install I did [00:03:16] <klondike> a week or two ago [00:03:18] <Zorry> klondike: hardened? [00:03:22] <klondike> yes [00:03:28] <klondike> hardened stage 3 [00:03:37] <klondike> but you can test yourself [00:04:17] <klondike> untar the stage and check the output of rc-status irc [00:04:58] --> alec-b ([email protected]) has joined #gentoo-hardened [00:06:45] <Zorry> klondike: it can been fixed but it did fail for a long time [00:06:56] <klondike> I know [00:07:08] <Zorry> now we know what the prob is [00:07:09] <klondike> had lots of complains about it [00:08:04] <Zorry> next? [00:08:15] <klondike> that bug was likely opened by one if the guys who complained to avoid the pain to the next one [00:08:23] <klondike> yes [00:08:26] <Zorry> 8.0 Media [00:08:46] <klondike> nothing [00:08:57] <klondike> as said forced leave :-( [00:10:09] <Zorry> 9.0 Open floor [00:10:18] <Zorry> ty for the meeting
[22:06:36] <Zorry> 1.0 Toolchain [22:07:12] <Zorry> toolchain are working on a news item if you have read the gentoo-dev list [22:07:36] <SwifT> for the ssp stuff? [22:07:43] <Zorry> when it is done default gcc 4.9.0 and 4.8.3 will have ssp enable by default [22:08:30] <SwifT> we might want to document the differences between the "default" toolchain and hardened then for our users [22:08:34] <Zorry> i still work on the upstream pie patches for gcc 4.10.x [22:08:43] <Zorry> SwifT: yes [22:09:41] <Zorry> i will try the pie stuff fist upstream then move to ssp [22:09:54] <Zorry> when pie is okay upstream [22:10:07] <Zorry> any qa on it? [22:10:13] <blueness> Zorry, i have a question about turning off ssp on hppa and other arches that don't support it. i know there's SSP_STABLE but if i read the eclass correctly, it seems that it only check that variable if the specs is hardened, have people checked that we can disable it [22:10:24] <prometheanfire> Zorry: ok [22:10:55] <blueness> ie disable it with vanilla with default ssp on? [22:12:27] <Zorry> blueness: ssp should be off on hppa when it is not in the ssp_stable [22:13:46] <klondike> :) [22:13:51] <blueness> Zorry, but checking SSP_STABLE is contingent on the spec, but we'll see [22:14:03] <blueness> i don't have access to hppa so i can't really test [22:14:21] <blueness> i'lls how you the eclass code i'm worried about after the meeting [22:14:46] <blueness> Zorry, are you done? can i talk about musl? [22:14:57] <Zorry> blueness: over to you [22:15:04] <SwifT> blueness' eager to talk about musl ;) [22:15:10] <Zorry> lol [22:15:42] <blueness> eager to get finished ;) [22:16:02] <blueness> yeah i just wanted to ask people to look over this -> https://wiki.gentoo.org/wiki/Project:Hardened_musl [22:16:05] <blueness> before i announce it [22:16:22] <blueness> i have just to add one contributor, unfortunately there is no way to do that in the template [22:16:45] <SwifT> just create a table like we did for the Hardened & SELinux projects [22:16:48] <blueness> Felix Janda in Germany has been working very hard with me [22:17:02] <blueness> SwifT, thanks and feel free to fix any formatting issues [22:17:06] <blueness> i suck at that [22:17:28] <blueness> in a couple of days i'll announce it, but i feel good about the porting because now everything is working in catalyst [22:17:46] <blueness> so the level of hackiness is significantly better than it was before [22:18:19] <blueness> okay that's it, and thanks SwifT for your documenting guru help :) [22:18:21] <SwifT> i'll see what I can help with on the wiki stuff [22:18:37] <SwifT> it's nice to see the project go live though [22:19:12] <blueness> i'm starting to feel that musl will be the future of embedded over uclibc [22:19:22] <blueness> unfortunately uclibc development upstream is stalling [22:19:25] <blueness> and not releasing [22:19:31] <blueness> patches are applied but no release [22:19:40] <blueness> and more and more the patches are glibc-ish [22:20:09] <blueness> anyhow, i'm done, i just wanted a second eye [22:20:14] <prometheanfire> ya, for embedded things I've been looking more and more into musl [22:20:44] <blueness> prometheanfire, i will be doing some benchmarking on speed but its clear musl > uclibc > glibc where > means "faster" [22:21:09] <prometheanfire> indeed, that's what I've found as well [22:21:23] <prometheanfire> musl with container namespacing is sexy [22:21:28] <prometheanfire> +1 [22:21:30] <prometheanfire> next? [22:21:49] <Zorry> any one else or next? [22:21:56] <SwifT> next is ok [22:22:05] <Zorry> 2.0 Kernel and Grsec/PaX [22:22:28] <prometheanfire> should we talk about CVEs? [22:22:28] <blueness> okay [22:22:42] <blueness> there were two major bugs against the vanilla kernel [22:22:55] <klondike> *badumtss* [22:23:01] <blueness> a pty race and a priv escalation in futex code [22:23:18] <blueness> both were fixed in vanilla and both fixes are only in the very latest stables [22:23:44] <blueness> so we have some stable kernels which are exploitable but i don't want to take them off the tree just yet [22:24:02] <blueness> because the latest stables (which were rapid stabilized) may not be as stable as we like [22:24:32] <klondike> blueness: I tried to exploit the pty race [22:24:39] <blueness> already perfinion says he's hit some panics with 3.14.2-r2 and i've asked him to open bugs so we can get pipacs and spender to fix asap [22:24:50] <blueness> klondike, and? [22:24:55] <klondike> After an hour running all I could get where oopses and that was on a non hardened kernel [22:25:09] <klondike> I can try to run it here too I think [22:25:19] <klondike> The futex one I should try [22:25:23] <prometheanfire> klondike: from what I know it's hard to get past the dos portion [22:25:31] <prometheanfire> and no poc code exists for the futex bug [22:26:06] <blueness> klondike, i think pipacs said that the hardened kernel was never susceptible to the pty race [22:26:38] <prometheanfire> indeed he did [22:26:49] <klondike> :) I'm still interested in testing but I wouldn't be surprised [22:26:56] <blueness> prometheanfire, i don't remember how certain he was about it though [22:27:13] <blueness> the pty was different, the futex was definitely exploitable [22:27:18] <prometheanfire> I remember it in passing only [22:27:19] <SwifT> wasn't that mostly because of symbol access that's prevented? [22:27:26] <blueness> yeah [22:27:56] <blueness> there is one more issue [22:28:19] <blueness> KSTACKOVERFLOW the new option caused some problems with some drivers [22:28:27] <prometheanfire> zfs iirc [22:28:32] <blueness> like i hit it with the virtio iface [22:28:37] <blueness> and yeah some peple said zfs [22:28:43] <blueness> so i recommend it to stay off [22:28:52] <blueness> it is off by default but people like a new toy [22:28:58] <blueness> so ... [22:29:08] <prometheanfire> make a note in topic? [22:29:20] <blueness> on a production systems - best advice is use 3.2.59-r5, turn KSTACKOVERFLOW off [22:29:29] <klondike> this should go on doc I'm afraid :( [22:29:51] <klondike> blueness: does the linux config help say anything about it? [22:29:58] <blueness> prometheanfire, go ahead, check the spelling on KSTACKOVERFLOW i'm pretty sure i have it right but i do have some dyslexia [22:30:05] <blueness> klondike, lol no [22:30:33] <blueness> it never does, but by the time we document it in Kconfig spender will probably have it fixed, i'd rather just announce [22:30:39] <SwifT> =) [22:30:49] <prometheanfire> cool [22:31:20] <blueness> i hope all hardened-sources users are on the email list, that's one quick way, the other is to use news with selection but news is so annoying to push out [22:31:26] <blueness> politically annoying [22:31:44] <SwifT> use mailingilst and blog posts [22:31:48] <blueness> yeah [22:31:51] <klondike> We can (should) have a doc just saying "Known issues" [22:31:54] <blueness> okay wait one more thing!!!! [22:32:08] <blueness> so i lied about one more thing before ... i do have one more [22:32:17] <blueness> this one is very very annoying, but i *finaly* have a handle on it [22:32:22] <blueness> its the install-xattr thingy [22:32:23] <blueness> so [22:32:26] <blueness> history first [22:32:31] <blueness> we had install.py [22:32:34] <blueness> it works great by slow [22:32:42] <blueness> zmedico added it to portage [22:32:46] <blueness> but he wrapper it [22:32:59] <blueness> so portage has a wrapper to a wrapper to /usr/bin/install [22:33:07] <blueness> BUT [22:33:36] <blueness> /usr/lib64/portage/bin/ebuild-helpers/xattr/install -> /usr/lib64/portage/bin/install.py -> /usr/bin/install [22:33:40] <blueness> here's the problem [22:33:59] <blueness> the environment $PWD is lost in the wrapping to the wrapping [22:34:21] <blueness> zmedico added somethig to my install.py which picked up the correct PWD but I didn't understand it [22:34:30] <blueness> so when i wrote my c wrapper i lost that variable [22:34:58] <blueness> so when you try to use it with portage, i loses the $S directory as PWD and can't find the files to install!!! [22:35:28] <blueness> this was a nasty nasty bug, but i finally tracked it down, its now just a matter of writing the code to preserve $PWD through the wrapper hell [22:35:41] <blueness> the new C wrapper path will be [22:36:01] <blueness> /usr/lib64/portage/bin/ebuild-helpers/xattr/install -> /usr/bin/install-xattr -> /usr/bin/install [22:36:13] <blueness> and each -> is a fork/execve [22:36:29] <blueness> and each fork/execve must preserve envp[] or at least $PWD [22:36:37] <blueness> end of long analysis [22:36:50] <chutzpah> blueness: uh you have cleanup to do after install? [22:37:01] <blueness> nope [22:37:03] <chutzpah> if you don't have to do cleanup, why fork? [22:37:16] <chutzpah> just execve the child command [22:37:28] <blueness> chutzpah, oh okay if by cleanup you mean copy over the extended attributes, then yes, i must do "cleanup" [22:37:43] <SwifT> there's postprocessing needed [22:37:54] <blueness> so its not really "cleanup" so much as run getfattr/setfattr on the files just installed by the system install [22:38:09] <blueness> SwifT, post processing is the better way to characterize it [22:38:12] <chutzpah> it seems like 3 layers of fork/execve is unnecessary [22:38:37] <blueness> chutzpah, i agree, but i can't get the portage people to focus on this [22:38:54] <chutzpah> blueness: radhermit has been working on this stuff in pkgcore [22:39:08] <blueness> zmedico knew what he was doing, i didn't question the layers he added [22:39:39] <blueness> chutzpah, i'm not sure how much he might be able to help, is it an xattr issue there too? [22:40:41] <chutzpah> blueness: he is trying to replicate the portage functionality with xattrs but make it actually have reasonable performance [22:40:58] <chutzpah> I don't entirely know what the state of that is at the moment [22:41:09] <blueness> chutzpah, i can ask him but for now i have a solution [22:41:36] <blueness> imo we need help in portage, i'm getting the impression its a pretty scatter team right now, i hope i'm wrong [22:41:50] <blueness> its a large codebase, well written but large [22:42:04] <blueness> zmedico was the man [22:42:10] <chutzpah> uhhh [22:42:21] <chutzpah> portage is many things, but well written is not one of them [22:42:41] <SwifT> we shouldn't focus on that right now (in this meeting) do we? [22:42:46] <blueness> lol okay, let's move on [22:42:50] <chutzpah> that's part of the problem, the code is extremely hard to follow [22:42:55] <Zorry> next? [22:42:58] <blueness> yes [22:43:07] <Zorry> 3.0 SeLinux [22:43:19] <SwifT> The 20140311-r2 policies are stable in tree, r3 is ~arch since may 29th [22:43:43] <SwifT> the selinux userpsace (version 20140506) is ~arch as well (somewhere beginning of may), stabilization had to wait until the multilib stuff was cleared [22:44:02] <SwifT> I had some good help from Arfrever with getting multilib working [22:44:33] <SwifT> on the userspace part, policycoreutils recently had a security vlnerability [22:44:36] <prometheanfire> refpol moved to gitgub [22:44:57] <SwifT> we worked around it (as the fix isn't truly inside policycoreutils, but how it interacted with a different library) [22:45:08] <SwifT> now, the vulnerability wasn't immediately applicable to us [22:45:25] <SwifT> you had to do some policy changes, set a non-default USE flag, etc. before you could possibly exploit it [22:45:38] <SwifT> but still, it's no longer applicable [22:45:56] <SwifT> like prometheanfire said, refpol and setools moved their codebase to github [22:46:09] <SwifT> for us, that hardly has impact (I just had to change git origin and continue patching ;) [22:46:22] <SwifT> which again showed me how wonderful git is as a vcs [22:46:27] <blueness> yep [22:46:40] <SwifT> selocal is updated with better input validation [22:46:54] <SwifT> (selocal = script to easily add small selinux policy enhancements) [22:47:27] <SwifT> and finally, I changed the profiles/features/selinux profile to ditch USE=-acl. I don't know why it was in, but I've been running it on over 100 systems with USE=acl on SELinux without problems [22:47:52] <SwifT> that's it for SELinux frmo my part [22:48:18] <klondike> SwifT: we should ditch it from hardened if it is there too [22:48:46] <klondike> I suppose they ditched them to reduce the accessible surface and to make missconfiguration by users harder [22:48:47] <SwifT> nope, it's not there [22:48:48] <blueness> was that the only reason it was there? [22:49:13] <SwifT> i don't know what the reason was anymore (i don't recall it being documented in the profile) [22:49:24] <klondike> blueness: it's the only one I can think off like with ipv6 [22:49:42] <blueness> klondike, how is it needed with ipv6? [22:49:43] <klondike> I also USE enable acl on all my systems as acls are very useful [22:49:52] <SwifT> hence my exhuberant testing before updating the profile [22:50:10] <klondike> blueness: the logic with ipv6 was smaller surface == less risk [22:50:28] <klondike> Also the risk of missconf of firewalls and stuff [22:50:54] <Zorry> next? [22:50:59] <SwifT> yup [22:51:08] -*- klondike nods [22:51:09] <Zorry> 4.0 System Integrity [22:51:52] <SwifT> not much to say; I try to keep http://dev.gentoo.org/~swift/docs/security_benchmarks/ up t date with what I know, but I still have lots of work on that to do [22:52:14] <SwifT> SELinux is my main focus right now, but with the holidays coming up I'll have more time for integrity [22:53:15] <klondike> SwifT: do you have access to TPM hardware? [22:53:27] <SwifT> I do now, yes [22:53:30] <klondike> :) [22:53:46] <klondike> just wanted to be sure :) [22:54:11] <Zorry> next? [22:54:14] <SwifT> yup [22:54:27] <blueness> yes [22:54:32] <Zorry> 5.0 Profiles [22:55:04] <klondike> Can I bring up USE=acl now? :P [22:55:19] <SwifT> if you really have to :p [22:55:44] <klondike> It would be nice to have it enabled on hardened profiles, or at least not disabled [22:55:53] <blueness> klondike, in that case caps too [22:56:00] <klondike> blueness: yes caps too [22:56:15] <SwifT> the policycoreutils issue was due to libcaps-ng :p [22:56:23] <klondike> Providing minimal privilege is oart of hardening [22:56:25] <SwifT> just sayin [22:56:38] <blueness> SwifT, that is not a trivial point [22:56:45] <blueness> let me make a recommendation ... [22:57:00] <blueness> if acl is on right now on *all* hardened profiles [22:57:02] <blueness> leave it on [22:57:23] <blueness> caps is not there, leave it off right now, we can do testing to see what might break [22:57:26] <blueness> and then turn it on [22:57:42] <blueness> because you never know what a use flag at that critical point might trigger [22:58:02] <klondike> I'd first bring it to the lists to collect opinions or any strong opositions too [22:58:11] <blueness> after testing we can add it, it would fix +s on /bin/oing [22:58:29] <klondike> bluenes tcpdump too [22:58:39] <blueness> klondike, sure, i'm just cautioning against adding something that seems innocent [22:58:43] <Hello71> I thought our suid was reasonably safe [22:58:46] <blueness> klondike, yeah tcpdump and a few others [22:58:49] <SwifT> i know you suggested cap'ifying gentoo and to remove setuids about a year or so ago [22:58:56] <SwifT> it might be time for a new round ;) [22:58:57] <blueness> i think caps would be more useful to hardened than acl really [22:59:14] <prometheanfire> ya, removing setuid would be nice [22:59:16] <blueness> we have that, someone did a GSoC on it [22:59:28] <blueness> and vapier fixed up the fcaps eclass and got it working [22:59:32] <SwifT> i love caps; I use it to gain root access to dev machines at work without the "real" admins knowing :p [22:59:46] <blueness> SwifT, yeah i guess it is abuseable [22:59:47] <prometheanfire> LOL [23:00:01] <blueness> but also grsec's rbac uses caps as one of its learning criteria [23:00:01] <klondike> Hello71: suid is a bad idea, because if it is breached then you can do anything you want with that user [23:00:17] <klondike> With capabilities you limit the reach of the attacks to the affected capabilities [23:00:38] <Hello71> klondike: I mean with that ptrace thing [23:00:41] <SwifT> it's not perfect.. cap_sysadmin is still quite powerful, and often needed [23:01:00] <SwifT> but for ping and such is cap_netsomething more than sufficient [23:01:14] <Hello71> cap_net_raw [23:01:18] <blueness> take a look at net-misc/iputils fcaps.eclass [23:02:00] <blueness> SwifT, i think we might be able to add caps pretty easily to the hardened profile, the issue will be to get maintainers with cap-ifyable packages to cap-ify them [23:02:49] <blueness> klondike, do you want to spearhead the USE=caps thing (i'm overwhelmed with projects and subprojects right now) [23:03:11] <klondike> blueness: If I can start on July yes [23:03:30] <klondike> but I'll need a proxy probably to do any tree commits [23:03:56] <SwifT> ebuild modifications probably need to go through bugzie to the maintainers [23:04:15] <SwifT> it'll be a matter of checking our profile & eclass (foundations) and then the ebuild work [23:04:27] <klondike> yeah I can try to find setuids on the ebuilds [23:04:57] <blueness> klondike, commit on hardened-dev overlay [23:05:03] <klondike> Shouldn't be too hard unless I need to ask for Zorry's jasmin :P [23:05:14] <klondike> blueness: oki I'll do so [23:05:27] <klondike> But as I said until July I can't get too involved [23:05:51] <blueness> klondike, also don't forget our hardened-dev::profiles overlay with is the profiles and you can mount --bind them over your local profiles to see what gets affected [23:06:19] -*- klondike nods [23:06:41] <klondike> So first we check for use caps then try to expand from there? [23:07:22] <blueness> yes [23:07:26] <SwifT> first make sure we're ready for caps and that ebuild devs can easily, and on a well documented approach, update their ebuilds [23:07:49] <klondike> Oki [23:08:13] <klondike> blueness: what about USE=acl? [23:08:26] <klondike> My understanding is that it is probably disabled on non SELinux [23:08:30] <perfinion> there is also USE="filecaps" [23:08:38] <blueness> klondike, its on so leave it [23:09:06] <blueness> we need to see if thats a repeat USE flag and nix it for caps if it is [23:09:51] <perfinion> blueness: wireshark and qemu have both caps and filecaps so no idea but yes it should be looked into [23:10:01] <blueness> perfinion, your job ;) [23:10:28] <blueness> we don't use the passive voice in hardened "it should be looked into" we use the active voice "i will look into it" ;) [23:10:37] <SwifT> :) [23:10:47] -*- blueness will stop with motivation psycho babble now [23:10:57] <SwifT> let's continue shall we? ;) [23:10:59] <blueness> yes [23:11:06] <SwifT> before we all get workload assigned by blueness XD [23:11:14] <Zorry> :D [23:11:32] <Zorry> i have some stuff on the profile [23:11:39] <SwifT> go ahead [23:12:05] <Zorry> with the new mulilib thing (abi_x86) [23:12:14] <blueness> ah yes! [23:12:41] <Zorry> i need to add pic use flag on some package for the x86 part [23:12:54] <Zorry> on the amd64 profile [23:13:48] <Zorry> done [23:13:52] <Zorry> next? [23:14:06] <prometheanfire> ja [23:14:19] <Zorry> 6.0 Docs [23:14:44] <SwifT> well, I did a rework on the SELinux documentation, which now almost resides fully on the wiki [23:15:06] <SwifT> it splits the various concepts/topics of SELinux out and makes it directly accessible [23:15:15] <SwifT> there's also a quick intro to SELinux on it for newcomers [23:15:30] <SwifT> I'm still not satisfied with it, but it's okay for now :p [23:15:43] <SwifT> for more info -> https://wiki.gentoo.org/wiki/SELinux [23:16:10] <SwifT> i'm going to focus on policy development documentation (and policy development in general) in july [23:16:48] <SwifT> on the xattr stuff, we just got some feedback on our mailinglist, but I still have to look into that [23:16:58] <SwifT> it was a mail regarding the xattr-pax migration [23:18:07] <SwifT> that's it for docs frmo my part [23:18:30] <Zorry> The emutramp should be documented that it need to be on in the config help on the kernel and the wiki [23:19:26] <SwifT> can't we also add in a check in the libffi ebuild (if use pax; ...; fi) [23:19:38] <SwifT> i mean, it's mainly due to the libffi stuff in python, not? [23:19:54] <SwifT> so a kernelconfig check in either of those ebuilds might also give some leverage [23:20:22] <SwifT> (just a suggestion - I totally agree with the documentation on emutramp) [23:21:06] <Zorry> blueness: can you add a note on that in the config help? [23:21:36] <blueness> Zorry, i read that Kconfig help, i'm not sure what else to add, just maybe that in Gentoo you really don't want to turn this off [23:22:01] <blueness> it is on by default, people have to manually turn it off [23:22:13] <Zorry> SwifT: can check with toolchain to add a check for it [23:22:49] <blueness> Zorry, should the emutramp thing go in the pax quikstart? [23:23:00] <Zorry> blueness: yes [23:23:59] <blueness> okay i need to add that and the stuff about user_xattr to fstab [23:24:01] <Zorry> just that on gentoo it need to be on [23:24:30] <blueness> Zorry, yeah because the explanation there is pretty clear in brad's help [23:26:30] <Zorry> next? [23:26:39] <SwifT> yup [23:26:49] <Zorry> 7.0 Bugs [23:26:54] <klondike> Oh [23:26:57] <klondike> I have one [23:27:06] <klondike> https://bugs.gentoo.org/show_bug.cgi?id=513064 [23:27:42] <klondike> This one seems to affect also other parts but I have to deepen on it [23:27:46] <SwifT> !bug 513064 [23:27:47] <willikins> SwifT: https://bugs.gentoo.org/513064 "sys-power/nut unable to use the usbhid-ups driver with CONFIG_GRKERNSEC_SYSFS_RESTRICT"; Gentoo Linux, Hardened; CONF; klondike:hardened [23:28:42] <klondike> Basically either we add finer granularity there or a whitelisted group as done with /proc or that option loses a lot of usefulness [23:30:12] <blueness> klondike, yeah typical [23:30:48] <blueness> i doubt spender would do that, we can (and have) in the past looked at excempting a /sys entry [23:31:02] <blueness> its pretty easy actually there's a place in the kernle source where those perms are set [23:31:20] <blueness> you identify what nut needs and pull the out of the ifdef defined by grsec's option [23:31:39] <klondike> Yeah but I think we shouldn't have exceptions [23:31:39] <blueness> klondike, maybe we sould point it out to spender first becuse nut is pretty popular [23:32:03] <klondike> It makes more sense to me to have a whitelist group instead to limit reach [23:32:12] <blueness> klondike, nut probably needs that stuff so either run nut with the permissions needed or make one exception [23:32:51] <klondike> blueness: yes nut needs it :P Otherwise it will not recognize the UPS [23:32:54] <blueness> well, i guess but that could be something you can get via rbac, but then you're bringing in a whole new machinary [23:33:19] <blueness> does nut run as root? [23:33:35] <prometheanfire> I think I maintain nut [23:34:03] <wip_> nut has its own user [23:34:18] <klondike> blueness: it runs as the nut user [23:34:40] <klondike> prometheanfire: you do? [23:34:46] -*- klondike goes fetch the whip [23:35:26] <blueness> prometheanfire, heh, if you do find out what permissions you coudl give to nut to get it to work, don't actually do it, just find out what file(s) in /sys it needs and we'll go fromthere [23:35:41] <SwifT> guys, I need to go to sleep (daughter's going to wake me up too soon tomorrow :/ [23:35:50] <blueness> i don't think we should get into details of that bug during the meeting, but this is a typical class of bugs with the hardened kernel [23:35:57] <blueness> SwifT, good night dude! [23:36:05] <Zorry> SwifT: gn8 [23:36:41] <klondike> blueness: yes it is [23:36:48] <klondike> Will approach spender :P [23:37:27] <blueness> yeah i think a whitelist might work, but i don't think he'llw ant that [23:37:44] <blueness> you might be able to add nut to the wheel group, that might be sufficient, but you'd have to check [23:38:11] <klondike> Wheel? [23:38:27] <prometheanfire> klondike: I added myself but have not done anything with it [23:38:51] <prometheanfire> blueness: I'm going to need a summary of what I need to look for [23:38:52] <blueness> klondike, yeah the wheel group [23:38:59] <prometheanfire> have been distracted by work :( [23:39:01] <blueness> prometheanfire, lsof / | grep nut [23:39:13] <Zorry> next? [23:39:21] <blueness> see what files nut is opening and then go from there [23:39:26] <blueness> Zorry, yest next [23:39:31] <klondike> blueness: I think sys is not restricted by it but okay [23:39:36] <Zorry> 8.0 Media [23:39:54] <klondike> Defintiviely not drwx------ 5 root root 0 30 maj 19.53 kernel [23:39:57] <prometheanfire> blueness: maintain, not use [23:40:00] <Zorry> any thing else next? [23:40:06] <klondike> Zorry: little for me on media [23:40:16] <prometheanfire> anyway, I'll add it to my list, I need to set it up anyway [23:40:20] <klondike> I think pjschmitt was planning on preparing some talks about hardening [23:40:30] <klondike> On the states that is [23:40:53] <prometheanfire> klondike: I'm with him too [23:40:57] <klondike> I sadly haven't had time to do much preaching here :( [23:41:00] <prometheanfire> it's blackhat eu teaching [23:41:26] <klondike> No, the blackhat eu training got rejected for what he told me [23:41:34] <prometheanfire> hasn't told me yet :P [23:41:42] <prometheanfire> but ok [23:42:38] <klondike> Well i think that's it, it'd be nice if parker could say anything but he is probably busy or something [23:43:29] <Zorry> next? [23:43:31] <prometheanfire> n [23:43:34] <blueness> yes [23:43:34] <prometheanfire> next [23:43:34] <klondike> Yes [23:43:41] <Zorry> 9.0 Open floor [23:43:50] <blueness> nothing from me and i need to run [23:43:59] <Zorry> ty for the meeting
