[gentoo-hardened] Meeting log 2011-10-05

[gentoo-hardened] Meeting log 2011-10-05

[Magnus Granberg]

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

Hi

Log from the meeting 2011-10-05 20:00UTC

/Magnus

[-- Attachment #2: meeting-2011-10-05_20:00UTC.log --]
[-- Type: text/x-log, Size: 25840 bytes --]

[22:14:33] <Zorry> 2.0 Toolchain
[22:14:53] <Zorry> gcc 4.5.3 hase got stable :)
[22:15:08] <prometheanfire> no problems that I've noticed
[22:15:12] <Zorry> glibc-2.13 will be next on the stable list :)
[22:15:22] <prometheanfire> other then not autodetecting march on kvm guests
[22:15:39] <Zorry> prometheanfire: yep
[22:15:58] <Aleister> prometheanfire: did you get to the bottom of it?
[22:16:31] <Zorry> gcc-4.7 will go stage2 next mouth i think
[22:17:03] <prometheanfire> no update to bug 384149 in a week
[22:17:04] <klondike> stage2?
[22:17:06] <willikins> prometheanfire: https://bugs.gentoo.org/384149 "gcc detects cpu as pentium-m when using -march=native on qemu-kvm-0.15"; Gentoo Linux, Core system; CONF; mthode:qemu
[22:17:27] <prometheanfire> it's assigned to the qemu people, not the gcc herd
[22:17:48] <klondike> prometheanfire: WRT bug 384149 ask me later since I have some ideas
[22:17:48] <willikins> klondike: https://bugs.gentoo.org/384149 "gcc detects cpu as pentium-m when using -march=native on qemu-kvm-0.15"; Gentoo Linux, Core system; CONF; mthode:qemu
[22:17:49] <Zorry> klondike: yes stage1 add new stuff stage2 -> stage3 fix stuff
[22:17:55] <prometheanfire> klondike: kk
[22:18:00] <Aleister> prometheanfire: go qemu upstream i guess but later...
[22:18:19] <klondike> So stage2 should be an rc?
[22:18:24] <Aleister> klondike: kinda
[22:18:55] <klondike> understood :D
[22:19:00] <Zorry> klondike: stage1 -> stage2 -> stage3 -> rc
[22:19:18] <klondike> Oki so stage2 = alpha and stage3 = beta
[22:19:30] <Zorry> klondike: something like that
[22:19:30] <Aleister> kinda XD
[22:20:09] <Zorry> any one have some more to say?
[22:20:21] <Zorry> else we move to selinux
[22:20:30] <klondike> yup
[22:20:38] <klondike> Regarding pathscale
[22:20:55] <klondike> I have been working with the pathscale team to get propper PIE support
[22:21:23] <klondike> The only remaining issue is ld not being called with the S objects when linking the runtime
[22:21:33] <klondike> Hopefully that'd get fixed soon :D
[22:21:43] <Zorry> k
[22:22:15] <Zorry> okay 4.0 Selinux
[22:22:22] <Zorry> SwifT gizmo prometheanfire
[22:22:28] <SwifT> on SELinux, most of the policy updates in the 20110627 version series are in ~arch for which a stabilization tracker now exists. I'm hoping to get most patches approved upstream (refpolicy) so that we can stabilize with an "accepted" policy ;)
[22:22:54] <prometheanfire> SwifT: tracker bug #
[22:23:07] <SwifT> getting the patches up is quite some work though, which is why there is little commits on gentoo cvs/svn/git by me, but many posts on refpolicy mailinglist
[22:23:18] <blueness> here
[22:23:23] <prometheanfire> blueness: that was quick
[22:23:24] <SwifT> https://bugs.gentoo.org/show_bug.cgi?id=384231
[22:23:50] <Zorry> blueness: we have you stuff last on the agenda
[22:23:50] <SwifT> there are a few items that prometheanfire reported that still need to be checked; that's something that should be done this week
[22:24:06] <blueness> Zorry, okay call on me when needed, its my fault
[22:24:54] <SwifT> other than that, it looks like the changes in refpolicy (move of modules towards a contrib repository) are not affecting the quality nor manageability of the policies, so that's a good thing
[22:25:24] <SwifT> also, the changes that I'm adding to the policy I'm trying to keep them logically cohesive so that they can be easily sent upstream
[22:25:28] <prometheanfire> puppet needs to be updated, along with kerberos, I should be working on them soon
[22:25:57] <SwifT> we might have a few policy changes that are not accepted by refpolicy - in that case, we either manage the changes ourselves (because we believe in them) or document them
[22:26:16] <SwifT> an example of "documenting" them is with prometheanfire's "bashlogger" request
[22:26:45] <SwifT> others will surely follow. fter all, we're talking about security policies, so that ought to be managed by the security admin (where we, as a distribution, offer a decent yet secure default)
[22:27:32] <SwifT> that's about all I have to say I think on selinux (documentation notwithstanding)
[22:28:00] <Zorry> prometheanfire: gizmo any thing ?
[22:28:08] <prometheanfire> non
[22:28:14] <Zorry> else we move on
[22:28:21] <gizmo> Hold
[22:28:49] <Zorry> gizmo: speek
[22:29:07] <gizmo> blueness, SwifT: do we want to talk about PeBenito ?
[22:29:11] <Aleister> idea make a roaster with stuff that is known to work with selinux :)
[22:29:38] <SwifT> gizmo: let me quickly catch up on those mails, but sure
[22:29:43] <gizmo> Ok
[22:29:47] <blueness> gizmo, I think that matter is better done via email
[22:29:54] <gizmo> blueness: ok
[22:30:01] <gizmo> Zorry: move on
[22:30:05] <blueness> we can report back here when we decide
[22:30:11] <Zorry> k
[22:30:29] <Zorry> 5.0 Profiles
[22:31:06] <Zorry> i will close the pic flag change tracer bug on amd64 profile
[22:31:28] <Zorry> !bug 348050
[22:31:33] <willikins> Zorry: https://bugs.gentoo.org/348050 "[Tracker] remove pic use flag as default on amd64 hardened profile"; Gentoo Linux, Hardened; CONF; zorry:hardened
[22:32:12] <Zorry> haven't have any more bugs on the tracker so far and that on i have is fixed
[22:33:15] <blueness> Zorry, that's pretty good, just one package
[22:33:42] <Zorry> blueness: yes but the configure should check it i think
[22:34:30] <Zorry> you should not need +pic in the IUSE as default
[22:34:58] <blueness> so patch configure.ac to check for pic?
[22:35:04] <blueness> in open-vm-tools?
[22:35:10] <Zorry> yes
[22:35:30] <blueness> i can look later
[22:35:33] <Zorry> k
[22:36:15] <Zorry> any one else have something to say?
[22:36:34] <klondike> Not me
[22:36:42] <Zorry> else move on then
[22:36:58] <Zorry> 6.0 Docs
[22:37:07] <Zorry> SwifT: klondike
[22:37:36] <klondike> On my side little changes done to docs on hardened side
[22:37:59] <SwifT> on SELinux, I'm updating the selinux handbook considerably with more focus on security administration and policy development. Most of the current content of course remains, but it'll be easier to read and more logically structured
[22:38:04] <SwifT> eta end of this month
[22:38:15] <klondike> I have one bug pending by Aleister (thanks!) and am working when I can on the toolchain with the notes I took from Zorry during Fosdem.
[22:38:20] <blueness> SwifT, one point i came across in the selinux docs
[22:38:37] <blueness> openrc's procfs does a mount -t selinuxfs selinuxfs /selinux
[22:38:43] <blueness> so you don't need it in fstab
[22:38:49] <blueness> the documents say you do
[22:39:02] <Aleister> :D
[22:39:06] <blueness> you should look at /etc/init.d/procfs and at the docs and see what should be done there
[22:39:18] <SwifT> blueness: ah k. if I forget to update it, bug me by bugzie or e-mail ;)
[22:39:28] <blueness> well two things:
[22:39:55] <blueness> 1) I think fstab doesn't need selinxu line because that's similar to how we do other pseudo file systems
[22:40:11] <blueness> 2) make sure /etc/init.d/procfs is doing it right, because it has
[22:40:16] <blueness>  mount -t selinuxfs selinuxfs /selinux
[22:40:20] <blueness> but I think we want
[22:40:27] <blueness>   mount -t selinuxfs none /selinux
[22:40:50] <blueness> It may make a difference if something parses for none in mtab
[22:40:57] <blueness> </end>
[22:41:09] <SwifT> yeah, I got something like that in my hilight records here
[22:41:19] <blueness> k
[22:41:31] <SwifT> I'll need to check when/if the stuff moves towards the /sys location though
[22:41:40] <blueness> k
[22:41:57] <blueness> so this is either a doc problem or a init script problem or both
[22:42:08] <blueness> i'll bug you if i don't see something
[22:43:27] <blueness> next?
[22:43:42] <klondike> Well
[22:43:46] <klondike> One last thing
[22:44:01] <klondike> I'm trying to arrange a talk in Malaga for next week
[22:44:08] <klondike> Will tell you if it happens in the end
[22:44:38] <Zorry> klondike: talk in media
[22:44:39] <klondike> Sorry
[22:44:43] <klondike> *Granada
[22:45:06] <Zorry> 7.0 Bugs then
[22:45:10] <klondike> yup
[22:45:26] <Zorry> any bugs to address?
[22:45:44] <blueness> kinda of
[22:46:03] <blueness> the rwx python bug keeps popping up randomly in places, and I can't figure out why
[22:46:31] <blueness> i've been looking at calculate linux which is gentoo based, and it has it
[22:46:44] <blueness> so this is very hard to trace down
[22:47:04] <blueness> anyone else encounter this?
[22:47:24] <Zorry> haven't try :(
[22:48:00] <blueness> well maybe we should document a work around
[22:48:14] <blueness> enable PAX_MPROTECT_COMPAT
[22:49:14] <blueness> i wish i understood it better, maybe an upgrade path issue, but that's the best I can do
[22:49:31] <blueness> no other serious bugs from my end
[22:51:13] <Zorry> SwifT: can we test the python thing on selinux? for i do have a rwx thing?
[22:51:29] <shadowdaemon> If you just work around it, it will become harder to track down?
[22:52:16] <blueness> shadowdaemon, i'm worried about people who are stuck with this on production machines and can't get rid of it
[22:52:31] <SwifT> what's the "rwx python bug"?
[22:52:34] <shadowdaemon> blueness: Ah I see.
[22:53:09] <blueness> SwifT, in python, when you import ctypes, you get the process killed by pax kernel with MPROTECT
[22:53:32] <blueness> we thought the problem was gone but it appears to occur in some systems
[22:53:53] <SwifT> blueness: so just "import ctypes" should be sufficient to (occasionally) trigger it?
[22:54:04] <blueness> eg calculate linux is pretty much vanilla gentoo, but if you put a pax kernel on it, python dies
[22:54:11] <blueness> SwifT, yes
[22:55:11] <blueness> okay i don't want to belabor this point, i wanted to see if others are still encountering it
[22:55:33] <Zorry> SwifT:  i think upstream selinux did have some prob to with the rwx on ctypes
[22:55:35] <gizmo> So, loop a python script that just 'import ctypes' within a bash shell might be enough to reporduce it?
[22:55:45] <Zorry> blueness: the bug nr.
[22:55:59] <blueness> gizmo, not even loop, just import
[22:56:18] <blueness> python -c "import ctypes"
[22:56:31] <SwifT> I don't have it (crashing) currently, but I'll see if I can schedule the thing so it gets run on various points in time
[22:57:04] <gizmo> blueness: right, but that doesn't always crash, right?  So loop it in a bash script 'till it crashes?
[22:57:17] <blueness> gizmo, no
[22:57:22] <blueness> on some systems it happens all the time
[22:57:27] <blueness> on others it never happes
[22:57:35] <blueness> same versions of python
[22:57:41] <blueness> we can't figure out what's different
[22:57:45] <gizmo> Does python do any kind of multi-threading?
[22:57:53] <gizmo> That sure sounds like a thread-race
[22:57:57] <Aleister> no
[22:58:04] <Aleister> it is highly none-threaded :p
[22:58:06] <gizmo> or buffer overrun
[22:58:19] <blueness> gizmo, python is capable of threading, but any python process is non-threaded
[22:58:24] <gizmo> ah
[22:58:30] <blueness> gizmo, its an mmap
[22:58:34] <gizmo> So, most likely a buffer over/underrun
[22:58:37] <blueness> but i can't locate it in the code
[22:58:42] <gizmo> ah, ok
[22:58:48] <blueness> so its an implicit mmap
[22:58:50] <gizmo> Yeah, those can be nasty.
[22:59:14] <klondike> blueness: I have to disagree
[22:59:15] <blueness> ie the mmap sys call is made but no directly from the mmap function
[22:59:23] <blueness> klondike, disagree with which statement?
[22:59:28] <klondike> blueness: I managed to trigger deadlocks on python
[22:59:35] <klondike> Using timers
[22:59:44] <klondike> So I have reasons to think it has some threading
[22:59:59] <klondike> *deadlocks on native code with a python interpreter as interface*
[23:00:14] <blueness> klondike, possibly but i'm pretty sure this is a memory mapping issue, not threading
[23:00:42] -*- klondike agrees
[23:01:17] <blueness> i'm done with this one, next?
[23:02:32] <Zorry> !bug 383317
[23:02:35] <willikins> Zorry: https://bugs.gentoo.org/383317 "sys-boot/grub-1.99 killed on hardened"; Gentoo Linux, Core system; CONF; mark:scarabeus
[23:02:55] <blueness> oh yes!
[23:02:58] <blueness> that one
[23:04:20] <blueness> i'm going to have to try grub 2 on one of my test systems and see for myself
[23:04:42] <prometheanfire> I've run grub2 but I think it was 1.98
[23:05:03] <Zorry> looks like a mess
[23:05:04] <blueness> prometheanfire, so its just a 1.99 issues?
[23:05:09] <blueness> Zorry, yes it does
[23:05:22] <klondike> prometheanfire: I cannot reproduce it with the version on my overlay :P
[23:05:37] <klondike> 64 bit system, that is
[23:05:43] <klondike> blueness: ^^^
[23:05:48] <prometheanfire> I'm fairly sure, unfortunately I don't have that system (was a old work laptop), haven't had it for over 4 months
[23:06:35] <Aleister> 1.98 works fine :)
[23:06:43] <Aleister> sounds like a 1.99 problem only...
[23:06:50] <klondike> 1.99_rc2 says here
[23:06:50] <blueness> 1.99 + amd64
[23:07:00] <klondike> Comming from my overlay
[23:07:25] <klondike> So the bad change is either fixed by one of my patches or was added between .99_rc2 and .99
[23:07:47] <klondike> blueness: ^^^
[23:07:53] <blueness> klondike, ty
[23:08:08] <klondike> Or well
[23:08:13] <klondike> maybe is the new compiler
[23:08:17] <klondike> but I doubt it
[23:09:07] <klondike> glib 2.2.5 according to objdump
[23:09:10] <klondike> *glibc
[23:10:28] <klondike> Anc can't tell the CC
[23:10:57] <klondike> Well any bugs more? I have one
[23:11:02] <Zorry> k
[23:11:08] <klondike> !bug 385437
[23:11:12] <willikins> klondike: https://bugs.gentoo.org/385437 "PAX failed -m"; Gentoo Linux, Hardened; RESO, DUPL; josan_pansa:hardened
[23:11:30] <Zorry> the mpg123 thing?
[23:11:43] <klondike> huh?
[23:11:47] <klondike> No, not that one
[23:12:14] <blueness> Zorry, that bug is confused
[23:12:25] <klondike> Gah can't find it
[23:12:42] <klondike> blueness: you remind the bug about the guy who enabled the pax USE?
[23:13:49] <klondike> Ohh yeah it is 385437
[23:14:08] <klondike> I think we should try too mask hardened uses outside hardened profile
[23:14:19] <klondike> to avoid people doing strange things without knowing
[23:15:08] <Zorry> that bug is a mess
[23:15:15] <blueness> +1
[23:15:22] <klondike> Yeah I agree
[23:15:41] <klondike> I was about to tell the guy to write in spanish and let me translate instead
[23:15:42] <Zorry> default kernel and toolchain so what do it have with pax?
[23:15:59] <klondike> Dunno, yet he said he had to put USE -pax in make.conf
[23:16:04] <klondike> That's what startles me
[23:16:39] <blueness> invalid
[23:16:51] <Zorry> what do the use flag get from ?
[23:16:52] <blueness> he needs support but it is not a bug
[23:16:58] <Zorry> yep
[23:17:05] <klondike> fair enough
[23:17:08] <klondike> then move on
[23:17:10] <Zorry> +1
[23:17:26] <Zorry> 8.0 Media
[23:17:39] <Zorry> klondike: 
[23:17:45] <klondike> Well let's make this fast
[23:17:58] <SwifT> +1
[23:18:03] <klondike> I made a twitter account
[23:18:05] <klondike> https://twitter.com/#!/GentooHardened
[23:18:31] <klondike> My main reasons were that security folks being one of our main sectors of users use it a lot
[23:18:50] <klondike> so we can use it to keep them informed and promote the project to those not used to it
[23:19:05] <klondike> And now the votes for declaring it an official team account
[23:19:10] <klondike> Anybody against that?
[23:19:55] <SwifT> nope
[23:19:58] <Zorry> it is okay for me
[23:20:24] <prometheanfire> ++
[23:20:25] <klondike> Fair enough then :D
[23:20:50] <klondike> If the idea works well we can try later identi.ca as Flameeyes sugested
[23:21:02] <Zorry> k
[23:21:11] <klondike> Also there is the talk in Malaga
[23:21:20] <klondike> I think this time if it happens will be in english
[23:21:28] <klondike> so will try to get it recorded
[23:21:43] <Zorry> nice
[23:21:47] <klondike> Also will look for another volunteer although they won't perform as well as lejonet
[23:22:24] <klondike> Regarding this years conference in brusel
[23:22:26] <klondike> *brusels
[23:22:31] <lejonet> :P
[23:22:33] -*- klondike can't get the name now
[23:22:40] <Aleister> fosdem?
[23:22:45] <klondike> yep fosdem
[23:22:55] <Zorry> will be there i hope :)
[23:23:01] <klondike> we should propose a talk there too if you agree
[23:23:01] <blueness> fosdem is mecca!
[23:23:02] <Aleister> +1
[23:23:11] <blueness> yes
[23:23:21] <blueness> i would love to help author a paper on hardened
[23:23:30] <Zorry> :)
[23:23:32] <SwifT> if there's need for room to stay during fosdem, that can always be talked about here too (I live not far from brussels)
[23:23:46] <Zorry> SwifT:  :)
[23:23:47] <klondike> hum
[23:23:52] <blueness> sleep over at SwifT  house!
[23:24:05] <klondike> SwifT: so we get to suffer your daughter?
[23:24:16] <SwifT> klondike: I'm going to put you in my basement
[23:24:18] <blueness> suffer?  = put up with?
[23:24:29] <klondike> xD
[23:24:43] <klondike> SwifT: if we meet you'll discover I really like children
[23:24:56] <klondike> I have lots of fun playing with them ^^
[23:24:58] <SwifT> I rather have people that don't really like children, much safer nowadays :p
[23:25:07] <Aleister> true true
[23:25:11] <klondike> SwifT: I have a small brother
[23:25:12] <blueness> sad
[23:25:26] <klondike> That's why I love children
[23:25:31] <lejonet> SwifT: :O
[23:25:34] <klondike> That brother has been almost a son to me
[23:25:35] <Zorry> keep the meeting clean pleas
[23:25:44] <klondike> Anyway let's move on
[23:25:51] <klondike> Nothing WRT media in here
[23:26:47] <Zorry> klondike: blueness do a paper on the stuff  and we try to get a talk on fosdem?
[23:27:12] -*- klondike needs credit so may be able to help with the paper
[23:27:20] <blueness> Zorry, i can sketch a paper, pass it by people for suggestions and then finish
[23:27:27] <Zorry> okay :)
[23:27:36] <blueness> klondike, we should author this as a team
[23:27:51] <klondike> its ok for me
[23:28:00] <blueness> like i said, i'll write out an outline, then you comment and then i fill in, and you fill in
[23:28:03] <klondike> there is heavy support for open source at chalmers ^^
[23:28:05] <blueness> and polish
[23:28:07] <blueness> and present
[23:28:10] <blueness> and get kudos!
[23:28:22] <klondike> blueness: feel free to take GentooHardenedWhy.odt as base
[23:28:44] <blueness> i'll look at it
[23:29:17] <klondike> http://klondike.xiscosoft.es/charlas/Hardened/GentooHardenedWhy.odt
[23:30:08] <klondike> Well let's move on?
[23:30:16] <Zorry> yes move on 
[23:30:22] <prometheanfire> ++
[23:30:25] <klondike> Ohh last thing
[23:30:39] <klondike> The slides in english have the notes almost translated
[23:30:54] <lejonet> klondike: siigh, why doesn't KTH have a heavy support for open source? :P
[23:31:00] <klondike> this is of special interest for those of you in the US in case you want to evangelize too
[23:31:31] <Zorry> 1.0 move pax mark to xattrs
[23:31:36] <Zorry> blueness:  ^^
[23:31:44] <blueness> okay guys quickly ...
[23:32:06] <blueness> we have two ways of marking PAX, EI_PAX and PT_PAX, both have advantages and disadvantages
[23:32:24] <blueness> EI_PAX will always work, but is limited compared to PT_PAX
[23:32:42] <blueness> PT_PAX sometimes breaks elfs
[23:32:43] <blueness> so
[23:33:08] <blueness> the best design to move forward is to migrate pax flags to xattrs
[23:33:19] <blueness> this requires several things:
[23:33:47] <blueness> 1) a userland utility that can do xattr pax markings, i already wrote this but its useless without 2
[23:34:05] <blueness> 2) kernel code to read xattrs from some namespace which has yet to be determined
[23:34:15] <blueness> that i have done nothing on
[23:34:44] <blueness> 3) get our package management system to support xattrs --- this boils down to getting tar to preserve xattrs
[23:34:47] <blueness> that is complete
[23:34:49] <blueness> also
[23:35:15] <blueness> 3 gives us the possibility to preserver selinux lables, posix caps and acls in portage
[23:35:30] <blueness> the pms team have to make this possible, but i will speak with them
[23:35:47] <prometheanfire> didn't you talk with picaps about the kernel side?
[23:36:05] <blueness> but already i have a patch against tar-1.6 to support xattrs
[23:36:20] <blueness> it is a fix of a fedora patch which they accepted their way and we should accept soon our way
[23:36:41] <blueness> prometheanfire, yes i spoke with pipacs, and he is okay with all of this, so i'm going to generate patches and pass stuff his way for inclusion there
[23:36:52] <Zorry> :)
[23:37:19] <blueness> so hopefully, one day, we will have 3 ways of doing pax markings, and we will prefer xattrs unless the filesystem doesn't support it
[23:37:31] <SwifT> cool
[23:37:44] <blueness> the work is being done here -> http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=summary
[23:38:02] <blueness> the RFC for the design is here -> http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=blob;f=doc/paxctl-ng-design.txt;h=9de06a0f9f1c426a7e129b7da53cc43760cd3976;hb=5fd12c4eb1c823348d86c70d261f42f202f06856
[23:38:17] <blueness> feedback welcome
[23:38:31] <Zorry> blueness: nice work :)
[23:38:41] <blueness> ty, but very incomplete
[23:39:20] <blueness> here's the xattr patch against tar -> https://bugs.gentoo.org/show_bug.cgi?id=382067
[23:39:41] <blueness> here's fedora's response -> https://bugzilla.redhat.com/show_bug.cgi?id=717684
[23:40:03] <blueness> so i feel confident about that patch
[23:40:26] <Zorry> we need some way in the portage to see what mark deps libs have so the bins get the same mark
[23:40:53] <blueness> ah Zorry, i started working on that too, but didn't finish it
[23:41:05] <Zorry> okay
[23:41:10] <blueness> http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=blob;f=scripts/revdep-paxmark;h=fd07c3ca38d4f2d87cfe3f1788fc42de6d507a21;hb=5fd12c4eb1c823348d86c70d261f42f202f06856
[23:41:24] <blueness> revdep-paxmark ^^^ based off of revdep-rebuild
[23:41:42] <blueness> finds libraries that are linked by binaries and compares pax flags
[23:41:51] <Zorry> :)
[23:42:01] <prometheanfire> that going into gentoolkit?
[23:42:01] <blueness> i stopped because i'm very iffy on this approach
[23:42:13] <blueness> prometheanfire, no i think its hardened only
[23:42:29] <blueness> so i've been putting elf related pax utilities in my repo .... elfix
[23:42:30] <prometheanfire> maybe include it if you have the hardened flag on?
[23:42:36] <blueness> not ready
[23:42:39] <prometheanfire> kk
[23:42:44] <prometheanfire> I mean eventually :D
[23:43:00] <blueness> maybe i'll finish it tonight, i got discouraged because i started doubting if this was the correct approach
[23:43:31] <blueness> because i don't want to create a utility that will start unravelling pax markings
[23:43:31] <klondike> blueness: the revdep-rebuild one?
[23:44:07] <blueness> klondike, no my revdep-paxmarkings --- find libraries that are linked by binaries that have different pax markings and migrate the markings from the library to the binary
[23:44:15] <klondike> yeah
[23:44:21] <klondike> well it is a good apprach
[23:44:29] <blueness> when you run a binary, the pax flags that are used for the process are those of the binary not the library
[23:44:30] <klondike> maybe not the best but should work
[23:44:47] <blueness> klondike, it will work, but you remember that scary conversation with pipacs!
[23:45:09] <blueness> if you change things so the pax markings of the library are taken on load, then we have a hole
[23:45:36] <blueness> an attacker can use the weakest pax marked library, link against it even if they don't use it and relax pax restrictions
[23:45:39] <blueness> so
[23:45:51] <klondike> I do :D
[23:45:52] <blueness> we can't go the way of the loader
[23:46:03] <blueness> (i know you do, reminding others here!)
[23:46:14] <blueness> or relaying to others
[23:46:28] <blueness> maybe this will be the only way for gallium users
[23:47:05] <Zorry> revdep-pax... should work
[23:47:50] <blueness> okay Zorry i'll finish it tonight ... while drinking beer :)
[23:47:59] <Zorry> hehe :)
[23:48:24] <blueness> btw this branch -> http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=shortlog;h=refs/heads/paxmark-libs
[23:48:43] <blueness> has some poc that shows just how pax markings works with binaries and libraries if you want to test for yourself
[23:49:00] <klondike> blueness:  I tested ^^
[23:49:01] <blueness> the README explains -> http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=blob;f=README;h=d8d2d8d4314fcccb101ce5d235649daab7756dde;hb=3632ea90232c98f9598e85395b20da2ccd9851f2
[23:49:05] <blueness> klondike, k
[23:49:25] <Zorry> next ?
[23:49:43] <blueness> yes
[23:49:51] <Zorry> 3.0 Kernel
[23:49:52] <blueness> (that was supposed to be short!)
[23:50:07] <blueness> nothing much to report on kernel
[23:50:27] <blueness> i will be stabilizing a 3.0 hardened kernel soon
[23:50:48] <blueness> there is one bug, virtualbox may have problems on 3.0
[23:50:51] <blueness> i haven't fully tested
[23:51:55] <blueness> when i've resolve that then i will stabilize, upstream is looking at it
[23:52:05] <Zorry> k
[23:52:14] <blueness> other than that, kernel is same as before, no changes
[23:52:27] <blueness> done
[23:52:30] <prometheanfire> virtualbox doesn't work on hardened anyway :P
[23:52:56] <Zorry> 9.0 Open floor then
[23:53:03] <Zorry> any one ?
[23:53:37] <klondike> xD
[23:53:45] <klondike> Sorry for spamming your twitter accounts ;)
[23:53:59] <klondike> blueness: SwifT ^^^
[23:54:06] <SwifT> I noticed :p
[23:54:10] <prometheanfire> klondike: remind me t dollow
[23:54:14] <prometheanfire> follow
[23:54:20] <SwifT> prometheanfire: follow
[23:54:32] <SwifT> Zorry: no, no open floor questions / topics here
[23:54:45] <Zorry> else i close the meeting and ty all