Re: Meetings logs from 2014-04-24 and 2014-06-13

[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 (~alec-MQLlO/[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