[gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Magnus Granberg]

[-- Attachment #1: Type: Text/Plain, Size: 98 bytes --]

Hi

The log form the meeting 2011-03-23 20:00 UTC

Hardened at Gentoo.org
Magnus Granberg (Zorry)

[-- Attachment #2: meeting-2011-03-23_20:00UTC.log --]
[-- Type: text/x-log, Size: 28734 bytes --]

[21:20:43] <Zorry> 1.0 Toolchain
[21:21:18] <Zorry> on gcc we have 4.6 in the dev overlay
[21:22:18] <Zorry> and gcc 4.7 have enter stage1 upstream so i need to start with the upstream patches for that
[21:23:05] <klondike> Zorry: upstream patches as in push patches to them?
[21:23:29] <Zorry> and we have one bug to fix the pch prob in gcc but it would be good i we could get some sort of randmmap upstream in the kernel
[21:24:05] <Zorry> klondike:push the esp patchset upstream
[21:24:16] <klondike> Good luck with it :D
[21:24:20] <Zorry> but it will be only for one arch
[21:24:45] <Zorry> and that is x86_64
[21:25:35] <Zorry> on glibc we have the sigaction bug fixed in 2.13-r2 i think it was
[21:26:11] <Zorry> any one have some more on that subject ?
[21:26:31] <klondike> hum one question
[21:26:57] <klondike> the randmmap issue, shouldn't it fix just by passing MAP_FIXED when mapping the headers?
[21:27:58] <Zorry> maby but we still need gcc upstream to fix it and that options is not in vanilla kernel
[21:28:29] <Zorry> so it may go the same way as glibc stuff do
[21:28:41] <Zorry> klondike:  if you see the point
[21:29:11] <Zorry> that way i would want randmmap upstream
[21:29:29] <klondike> MAP_FIXED is not on linux options? Drepper is also responsible for gcc?
[21:29:51] <Zorry> klondike: i men the randmmap in kernel
[21:30:47] <Zorry> klondike: no he is not but upstream need to reprodus it and stuff
[21:31:12] <klondike> Couldn't we just drop in the patch and explain why we do it?
[21:31:50] <Zorry> klondike:  we dont have any patch for pch gcc segfault
[21:31:58] <klondike> Ok
[21:32:06] <klondike> good point there, then :(
[21:33:13] <Zorry> klondike: do you have something more?
[21:33:32] <klondike> Nope, thanks for your work and answers Zorry :D
[21:33:37] <Zorry> k
[21:33:54] <Zorry> we jump over 2.0 kernel for now
[21:34:11] <Zorry> so 3.0 selinux   SwifT jump in
[21:34:26] <SwifT> k
[21:34:29] <SwifT> first, profile
[21:34:59] <SwifT> some people have asked if selinux and no-multilib is possible. The answer is simply "yes", we just have some weird things going on how portage is dealing with the various parent profiles
[21:35:25] <SwifT> however, if you start from the current no-multilib profile and just "enhance" it (in /etc/portage) with the stuff in the base selinux one, you get selinux + no-multilib
[21:35:45] <SwifT> I don't know much about profile development (creating a new folder in the overlay didn't allow eselect to find it and I just halted :)
[21:36:12] <SwifT> but the moment someone wants to give it a try, please go ahead and I'll have you supported with several dozen of kvm guests :)
[21:36:28] <SwifT> or if someone can tell me what to look for to create a profile, that's fine too
[21:37:03] <SwifT> so far for the profile stuff (if there are questions, just interrupt me :)
[21:37:08] <SwifT> next, policy/ebuilds
[21:37:15] <klondike> I can do the profile SwifT
[21:37:24] <klondike> Or help you with that
[21:37:30] <klondike> After the meeting ;)
[21:37:31] <lestat> ola here
[21:37:59] <SwifT> that's cool... even if it was just a head start in hardened-dev.git it would allow me to see if that works well
[21:38:04] <SwifT> lestat: que?
[21:38:55] <SwifT> ... okay. Well, klondike, I'll stay in touch with you on the profile thingie
[21:39:03] <Zorry> SwifT: /profiles/profiles.desc need to be updated with the new profile dir
[21:39:37] <Zorry> so eselect profile can se it
[21:39:54] <SwifT> ah k... things *can* be simple then :)
[21:40:19] <SwifT> i'm definitely going to give that a try the next few days. If it works well, i'll give a suggestion on gentoo-hardened@g.o
[21:40:45] <SwifT> from the sound of it, there are a few people waiting for no-multilib and selinux, so it has some priority at my side
[21:41:06] <SwifT> okay... next on to the policy/ebuild development
[21:41:26] <SwifT> the current set of ebuilds seems to work well, there are a few changes in hardened-dev.git pending but nothing major
[21:42:04] <SwifT> currently, policy development/maintenance focuses on amd64 (not ~amd64 nor any other architecture, although it might work well with others), strict policy (not targeted) and currently mostly on server-side
[21:42:31] <SwifT> strict -> if strict works, there's little things that might break targeted (although they exist as we've noticed)
[21:42:53] <SwifT> server-side -> most of our "customers" will use SELinux for servers, not desktop, so that's my primary focus for the time being
[21:43:12] <SwifT> also, I do run my graphical workstation with selinux/strict too, but I hardly use any graphical stuff so I'm no reference
[21:43:39] <SwifT> also, on the selinux-* naming: it looks like the trick with ~! (blocker) works well
[21:43:55] <SwifT> remember, we had some packages that were not named after the module (upstream) they contained
[21:44:27] <SwifT> by using auto-resolving blockers, we're able to introduce the correct names without (1.) renaming packages, or (2.) requesting users to emerge -C foo && emerge bar
[21:44:56] <Zorry> :)
[21:45:04] <SwifT> and lastly on the ebuilds/policy: as seen on the mailingilst, we might be working towards stabilization now
[21:45:25] <SwifT> we're not going to progress much further before we do this, as we need more coverage and need to clean the existing ebuilds
[21:45:39] <SwifT> also, it allows us to remove "loadpolicy" frmo the selinux profiles, which is a bugger
[21:46:30] <SwifT> and my last topic for selinux (non-docs related): I'm currently still running on 2.6.36; more recent kernels seem to have a higher binary version for SELinux (current is .24 and I've heard of people running with .25)
[21:46:52] <SwifT> this *might* have some impact on SELinux - frmo the looks of it, we might need to rebuild libsepol
[21:47:07] <SwifT> if not, some tools think they still need to work with the .24 policy
[21:47:23] <SwifT> I'm going to test that out the next few days
[21:47:27] <prometheanfire> anyone test selinux-asterisk yet?
[21:47:42] <prometheanfire> bah, I keep forgetting that I cant use selinux on nomultilib yet
[21:47:55] <gizmo> SwifT: On the issue of profiles, we really need to involve PeBenito in any changes made there.  There are some things that are a certain way for a reason, and I don't fully understand it all myself.
[21:47:58] <SwifT> prometheanfire: no, but if you could give me some pointers or documents on how to install and use asteriks that'd be great
[21:48:09] <SwifT> gizmo: of course
[21:48:22] <prometheanfire> SwifT: emerge asterisk and starting it via init will do the basics
[21:48:37] <prometheanfire> if you want to actually use it, then you will need a softphone to register to it
[21:48:57] <SwifT> gizmo: but I might imagine that PeBenito might want to start discussion from a suggestion (for instance draft policy) instead of asking him how we should proceed?
[21:49:35] <SwifT> prometheanfire: that's the culprit.. getting it to start in the right domain is no biggie to test, but I like to perform some testing to make sure that all (re)labeling is done correctly
[21:49:47] <SwifT> still, should be doable
[21:50:02] <gizmo> SwifT: Absolutely.  It's much better for us to approach him from the perspective of "Do you have any reason why we SHOULDN'T do this?" than from the perspective of "What do you think we ought to do?"
[21:50:08] <SwifT> prometheanfire: I tend to script all setups I test so that, with every change, I can easily have all things tested
[21:50:16] <SwifT> gizmo: ack
[21:51:07] <SwifT> that's it for me
[21:51:56] <SwifT> (damn, quite a monologue here :)
[21:52:07] <Zorry> hehe
[21:52:07] <Aleister> i might be able to start testing selinux+no-multilib next week or so :)
[21:52:59] <SwifT> see... the sooner we have selinux+no-multilib the more people to give it a try
[21:53:33] <prometheanfire> SwifT: problem is, with asterisk it is made to be interactive, so not easilly scripted)
[21:53:39] <prometheanfire> phone calls and all...
[21:54:02] <prometheanfire> SwifT: if you ever have the profile ready for testing I have a no-multilib setup I can test with :D
[21:54:04] <SwifT> prometheanfire: well, if I could get something like ekiga working with it then I should be able to work things out
[21:54:36] -*- SwifT has a set of 32 kvm guests ready to roll out and which get rebuild from scratch after every autobuild is uploaded :)
[21:54:44] <prometheanfire> ya, ekiga
[21:54:47] <SwifT> multilib or not shouldn't make a big difference
[21:55:24] <prometheanfire> well, lemme know when the profile is available
[21:55:39] <SwifT> I'll put a huge banner on www.gentoo.org :p
[21:56:01] <prometheanfire> :D
[21:56:19] <prometheanfire> how will selinux policies handle that, is it easy or hard?
[21:56:43] <SwifT> prometheanfire: a new profile? shouldn't be a problem afaict
[21:57:13] <SwifT> i've done all my tests on a no-multilib system with selinux without any hickups
[21:57:37] <SwifT> just not in a profile yet (only using the regular overrides in /etc/portage/profile)
[21:58:04] <prometheanfire> oh, so I can switch from my hardened/linux/amd64/no-multilib?
[21:58:20] <SwifT> prometheanfire: you can, yes
[21:58:52] <SwifT> prometheanfire: see http://thread.gmane.org/gmane.linux.gentoo.hardened/4820
[21:58:53] <Aleister> SwifT: are you planing on putting a development profile in the hardened-overlay?
[21:59:29] <SwifT> Aleister: i'm first going to try it on my own overlay to see if things break, then I would give a suggestion on the mailinglist and involve pebenito. Only then will i see to use the overlay
[21:59:42] <SwifT> the overlay is used by too many people to start fiddling with profiles for me
[21:59:59] <Aleister> yes yes just wondering :)
[22:00:13] <Aleister> but is your overlay public?
[22:00:28] <prometheanfire> SwifT: just so I don't mess things up I can switch from the hardened/linux/amd64/no-multilib to selinux/v2refpolicy/amd64/hardened for testing?
[22:00:35] <SwifT> it's on github, but hardly used by anyone (and if they do -> it's not managed with quality :p)
[22:01:06] <SwifT> prometheanfire: no, stay with hardened/linux/amd64/no-multilib but enable selinux using /etc/portage/profile files
[22:01:28] <SwifT> prometheanfire: selinux/v2refpolicy/amd64/hardened will always try to go for multilib (weird magic is happening there)
[22:01:30] <prometheanfire> ah, ok, no offence, but I don't like mucking in there, scary
[22:01:35] <SwifT> =)
[22:01:51] <Aleister> prometheanfire: lucky you i do :)
[22:01:57] <prometheanfire> Aleister: :D
[22:02:00] <prometheanfire> well, time to go home
[22:02:48] -*- SwifT hands over the floor back to Zorry 
[22:02:59] <Zorry> if non dont have something else to say we move on the next 4.0 Profiles
[22:03:07] <Aleister> go
[22:03:51] <Zorry> on profiles we did some clean up and change some of the inherit in the parent files
[22:04:33] <Zorry> and i have set -pic on the amd64 profiles and only one package so far need it on
[22:05:24] <Zorry> bluness know more what have been done but he is not online
[22:05:28] <Zorry> :(
[22:05:53] <Zorry> any one have more to say?
[22:06:03] <klondike> I think the one will become two
[22:06:23] <klondike> Having pic forcefully disabled for amd64 breaks some dependencies
[22:06:35] <Zorry> ?
[22:06:45] <klondike> One second and I'll tell you which one
[22:07:54] <klondike> ok here it is
[22:08:11] <klondike> sys-devel/llvm-2.8-r2 (udis86&amd64? dev-libs/udis86[pic])
[22:10:15] <Zorry> it is the same for default profile
[22:11:47] <Zorry> udis86 don't have pic set  as default so
[22:12:04] <klondike> Hum ok
[22:12:15] <klondike> but It doesn't set the -pic IUSE
[22:12:32] <klondike> so by default the use should take the value required by the dependencies I think
[22:13:34] <Zorry> it is up to the user
[22:14:23] <klondike> Ok maybe I misunderstood the ebuild guides then U_U
[22:15:00] <Aleister> if an ebuild requires a dep to be build with or with out a specific useflag it will check it and abort/fail (and post a nice message) if those flags haven been set correctly.
[22:15:10] <Zorry> portage dont set it on if not the iuse have +foo
[22:15:21] <Zorry> Aleister: yep
[22:15:39] <klondike> Ok my fault then
[22:15:51] <Zorry> that way it pain in .... with thinderboxing
[22:16:33] <Zorry> klondike: anything more ?
[22:16:39] <klondike> no
[22:16:56] <klondike> I'll keep an eye for PIC related issues though
[22:17:01] <Zorry> moveing to 5.0 Docs then
[22:17:09] <Zorry> klondike: ^^
[22:17:17] <klondike> Hum
[22:17:37] <klondike> Well there is not much done on my side with this mainly due to having the exams last week
[22:17:38] <shadowdaemon> Devs have x86 test machines?
[22:17:58] <klondike> shadowdaemon: why shouldn't they?
[22:18:05] <SwifT> I can tell some about the SELinux docs
[22:18:05] <SwifT> the SELinux handbook should be ready for pushing towards hardened.g.o
[22:18:27] <SwifT> same for SELinux FAQ
[22:18:27] <shadowdaemon> klondike: I just wondered.
[22:19:05] <SwifT> however, with SELinux policy development, we might want to wait a bit (or at least not link it directly) as we need more than just gizmo and myself to read it :)
[22:19:30] <SwifT> now, if we go for stabilization of the selinux ebuilds, we definitely want to have the new handbook up for the end user
[22:20:07] <SwifT> I'm also going to put a bit more focus on docs now again (well, after the no-multilib stuff) as new users will have a lot of questions which we need to tackle
[22:20:20] <klondike> Agreed, that or mark the current handbook as outdated and point to the new :/
[22:21:08] <klondike> SwifT: are you done?
[22:21:11] <SwifT> yup
[22:21:20] <klondike> ok on here
[22:21:39] <klondike> As I said we should mark the old handbook as outdated
[22:22:08] <klondike> As it is very confusing for new users and is not the first one asking about them
[22:22:25] <klondike> Zorry: would you mind proxying me for those changes?
[22:23:14] <Zorry> hit me with the needed changes so 
[22:23:17] <SwifT> we might just want to push the new one (it's already guidexml), because markign it as outdated will have the users ask for the new one
[22:23:35] <Zorry> good point
[22:23:37] <klondike> SwifT: to me is the same going for one of the other
[22:23:55] <klondike> We can mark as outdated and point to the new one
[22:24:05] <klondike> or we can just approve the new one and publish it
[22:24:16] <Zorry> +1
[22:24:17] <klondike> I think approving it is the best approach
[22:24:42] <SwifT> yeah, pointing towards a PDF is not what all users might want, and the preview option in the git isn't user friendly for handbooks :)
[22:25:16] <klondike> I can't give an opinion on wether the guide is ready or not as still didn't have time to follow it
[22:25:30] <klondike> but seeing the user's opinions I'd go for publishing it as it is
[22:26:20] <klondike> So lets go for the voting, people against publishing the updated SELinux guide and the FAQ?
[22:27:08] <Zorry> i would say do it
[22:27:12] -*- SwifT too
[22:27:14] <gizmo> +1
[22:27:14] <prometheanfire> +1
[22:27:17] <klondike> +1
[22:27:20] <SwifT> +1
[22:27:36] <klondike> Ok so nobody oposes then so it is aproved :D
[22:27:45] <Zorry> good
[22:28:06] <klondike> On other aspects I have been teaching prometheanfire a bit of git so he can start contributing
[22:28:17] <Zorry> nice
[22:28:24] <klondike> I'm not sure if he has already solved his issues with the keys, did you prometheanfire?
[22:29:16] <klondike> Well as he was heading home he may take some time to answer :/
[22:29:17] <prometheanfire> sort of
[22:29:26] <prometheanfire> quantumsummers|a has the same problem I do
[22:29:39] <Zorry> k
[22:29:51] <prometheanfire> I can git clone git@git.overlays.gentoo.org:/proj/hardened-docs.git now, and that uses the key aparently
[22:29:54] <quantumsummers|a> prometheanfire: I checked with infra, we are both +W on that repo
[22:30:04] <quantumsummers|a> prometheanfire: that method is preferred.
[22:30:10] <prometheanfire> +W?
[22:30:11] <quantumsummers|a> versus git+ssh
[22:30:18] <quantumsummers|a> write access = +W
[22:30:21] <prometheanfire> kk
[22:30:34] <quantumsummers|a> so, that repo you have is all good for you to commit
[22:30:55] <prometheanfire> so I would say that that aspect of it is solved
[22:31:02] <quantumsummers|a> I would agree
[22:31:12] <prometheanfire> I am going to be working on fleshing out the virt doc
[22:31:23] <quantumsummers|a> cool.
[22:31:27] <prometheanfire> I should have more to say by the next meeting
[22:31:44] <Zorry> :)
[22:32:18] <klondike> Next weekend (2/4 3/4) I'll probably give the course on guideXML so anybody who wants to come just give a look to http://www.gentoo.org/doc/en/xml-guide.xml and join the channel that will be announced since I'll assume you have looked at it.
[22:32:41] <klondike> ok bad woding
[22:32:52] <quantumsummers|a> woding, what is that?
[22:33:03] <klondike> Next weekend (2/4 3/4) I'll probably give the course on guideXML so anybody who wants to come just give a look to http://www.gentoo.org/doc/en/xml-guide.xml (since I'll assume you have looked at it) and join the channel that will be announced.
[22:33:10] <klondike> quantumsummers|a: wording
[22:33:21] <quantumsummers|a> klondike: ah, wording. ok ;)
[22:33:40] <klondike> on other aspect I did some small touches on the SELinux and hardened projects main pages
[22:33:49] <SwifT> bah, I'm having a DRP test that weekend so won't be able to join in :(
[22:34:24] <prometheanfire> klondike: you should specify the channel
[22:34:26] <klondike> SwifT: I doubt you need it :P
[22:34:47] <klondike> prometheanfire: lets say #gentoo-hardened-doc-course like last time?
[22:34:51] <SwifT> klondike: I meant to look over your shoulders and slap you with a stick if you make mistakes :p
[22:34:57] <klondike> xD
[22:34:58] <prometheanfire> klondike: tell others, not me
[22:35:13] <klondike> SwifT: if you want we can pick a better time for the three of us ;)
[22:35:17] <SwifT> =)
[22:36:16] <klondike> Ok so the channel and the time will be announced on the hardened list and in this channel topic
[22:36:28] <klondike> going back to the indexes
[22:36:50] <klondike> Then new looks are this: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/index.html;h=c3f4ea2caf4bd54262950e0a83f19db19a3588f9;hb=HEAD and this: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/selinux/hb-appendix-reference.html;hb=HEAD
[22:37:18] <klondike> I fixed some minor issues on some links on  the selinux page which were pointed by ago` IIRC
[22:37:45] <klondike> And added a section for non developers actively contributing on the projects as was requested
[22:37:59] <klondike> Anybody is against these changes?
[22:38:29] <SwifT> you should use URL shorteners in irc :p
[22:38:59] <Zorry> klondike: looks okay
[22:39:24] <klondike> SwifT: url shorteners are a cancer :P
[22:39:43] <klondike> Well if nobody has complaints on that we could go on and approve them too
[22:40:13] <klondike> There is also the TPE and the FAQ pending approval
[22:40:28] <klondike> the FAQ has some minor fixes which were pointed in bugs
[22:40:46] <klondike> and the TPE doc... well you know I want to see it published anytime xD
[22:41:31] <Zorry> will se if i could get some time this weekend klondike for commit the updated docs
[22:41:41] <klondike> Ok Zorry
[22:41:56] <klondike> I hope this happens before I get through the become a dev ordeal :P
[22:42:31] <klondike> Well I think this is all from docs
[22:42:36] <Zorry> k
[22:42:58] <klondike> When blueness appears I'll ask him about the TPE-doc so hopefully we can publish it too
[22:43:05] <Zorry> any one else?
[22:44:20] <Zorry> moveing to 6.0 Bugs
[22:44:43] <Zorry> any bugs to discuse?
[22:44:54] <klondike> hum
[22:45:05] <klondike> there are new bugs regarding docs
[22:45:14] <klondike> but I think I can handle them for now
[22:45:21] <Zorry> klondike: k
[22:45:25] <klondike> blueness: a buenas horas mangas verdes!
[22:47:49] <Zorry> okay and no anser from blueness so  meeting open for users
[22:47:59] <blueness> my router keeps kicking out
[22:48:01] <blueness> its a hardware issue
[22:48:04] <blueness> i missed the meeting, i'm sorry
[22:48:06] <blueness> Zorry, hardware issue
[22:48:08] <blueness> did you guys have the meeting?
[22:48:11] <klondike> yup
[22:48:15] <blueness> Zorry, i'm so sorry, i tried repeatedly but i had nothing but trouble
[22:48:20] <klondike> blueness: its not late enough
[22:48:35] <Zorry> blueness: take kernels then
[22:48:37] <klondike> go for the kernel and whatever you have to say man
[22:49:07] <blueness> kernel:
[22:49:30] <blueness> i've implemented the new predefined grsec settings
[22:49:44] <blueness> these are SERVER, WORKSTATION and VIRTUALIZATION
[22:50:08] <blueness> the first two are the same as before but with RBAC not disabled by default
[22:50:19] <blueness> VIRTUALIZATION is the lowest common denominator, unfortunately
[22:50:31] <blueness> i turned off KERNEXEC and UDEREF
[22:50:48] <blueness> although under some virt circumstances you can have one or the other, generally speaking both have to be off
[22:51:06] <blueness> the only remaining issue with virtualization and hardening is virtualbox's build system
[22:51:20] <blueness> i've tried to get -nopie in there but have not succeeded
[22:51:37] <blueness> a user has to manually switch to -hardenednopie to compile virtualbox
[22:51:49] <blueness> that's about it for kernel
[22:51:56] <blueness> also a little on selinux
[22:52:03] <blueness> its progressing slowly
[22:52:18] <blueness> but we at least have working policies thanks to swift
[22:52:52] <blueness> we've started naming policy ebuilds after upstream policy names to avoid naming conflicts, so cyrus-imap was fixed
[22:53:11] <blueness> and we're hoping to move towards stabilization
[22:53:23] <blueness> in the long run i may clean up those profiles, but stabilization is next
[22:53:31] <blueness> that's it for me
[22:53:36] <klondike> hum
[22:53:45] <klondike> on the kernel I forgot one thing
[22:53:47] <prometheanfire> blueness: what about no-multilib selinux?
[22:53:56] <blueness> prometheanfire, that's part of the profile thing
[22:53:59] <prometheanfire> ok
[22:54:00] <blueness> klondike, you mean your CVE?
[22:54:06] <klondike> yes
[22:54:26] <blueness> prometheanfire, swift tried the no-multilib and found no issues.  but there is no profile
[22:54:36] <blueness> i'll try to get one in
[22:54:45] <prometheanfire> thankyou
[22:55:04] <blueness> okay one more thing on kernel, klondike found a dos wrt to mmaping growing down and growing up
[22:55:15] <blueness> the fix is in the latest ebuilds in the tree
[22:55:17] <SwifT> nice
[22:55:24] <blueness> oh oh one more thing about kernel
[22:55:33] <blueness> a bug i didn't report yet but will have to address
[22:55:47] <klondike> for those of you worried on it don't worry it can't trigger privilege escalation at all, just a DOS
[22:55:55] <blueness> HP smart array, the CCISS driver is borked on 2.6.37 and maybe 2.6.38
[22:56:07] <blueness> this is a blocker to stabilizing 2.6.37 right now
[22:56:25] <prometheanfire> I thought that has been known for a while now though
[22:56:29] <blueness> if i can't resolve it, i'll make a patch to revert the commits that changed how the pci bus is read on those systems
[22:56:48] <blueness> prometheanfire, yes, but there's some confusion about it
[22:57:10] <blueness> some people think it works, i've asked chainsaw to confirm before i file the bug, he has the same systems
[22:57:40] <blueness> i think i've covered everything now
[22:58:16] <Zorry> blueness: did you talk to pipacs/spender about randmmap upstream
[22:58:35] <blueness> i did not
[22:58:38] <Zorry> k
[22:58:57] <blueness> i think we need to talk to them, i could isolate the patch from the ifdefs
[22:59:06] <blueness> but i need to see what their feeling is, its their code
[22:59:16] <Zorry> +1
[22:59:23] <blueness> let me say to the community: there are lots of bugs cropping up becuase or randmmap
[22:59:43] <blueness> it would be good to pull randmmap out of the grsec patches and submit it upstream
[22:59:54] <blueness> it has some chance of being accepted
[23:00:30] <blueness> if it were, it would pressue on some other projects to make their code work with randmmap
[23:00:47] <blueness> Zorry, okay right after this meeting i'll email both and see what they think
[23:00:58] <Zorry> okay
[23:01:26] <blueness> Zorry, besided pch what other bugs are coming up from randmmap?
[23:02:01] <Zorry> blueness: mono
[23:02:03] <klondike> blueness: count me in for the randmmap thingy
[23:02:15] <Zorry> and mor will come i think
[23:03:00] <blueness> Zorry, heh, i just wrote a little thing in C# and can't run it in hardened because of mono, irony
[23:03:25] <Zorry> hehe
[23:04:17] <shadowdaemon> I think the new OpenLDAP has problems with randmmap too.
[23:04:28] <blueness> shadowdaemon, that's serious
[23:04:29] <prometheanfire> shadowdaemon: 24 works for me
[23:04:36] <prometheanfire> on amd64
[23:05:08] <shadowdaemon> "munmap" complains when the programs finish.
[23:05:19] <prometheanfire> finsh compiling?
[23:05:21] <shadowdaemon> This is on x86.
[23:05:34] <shadowdaemon> prometheanfire: Finish executing.
[23:05:34] <SwifT> shadowdaemon: same here... been using it for centralized authentication without problems. Amd64 though
[23:05:47] <SwifT> (same here == no problems found)
[23:06:05] <prometheanfire> we need to install x86 plain sometime
[23:06:37] <shadowdaemon> Well my UMLs don't have PaX, and the problem doesn't occur on them.
[23:06:55] <Zorry> x86 is geting more and more problems for hardened
[23:07:07] <shadowdaemon> Sucks.
[23:07:36] <shadowdaemon> x86 is dying anyway I guess.
[23:07:47] <blueness> SwifT, i have to thank you for getting selinux in such a good shape.
[23:08:19] <blueness> i didn't want to loose selinux but could not have save it on my own
[23:08:35] <Zorry> gizmo SwifT thanks for the selinux work
[23:08:43] <SwifT> np it's fun
[23:08:48] <blueness> and gizmo too if he's around
[23:09:11] <prometheanfire> SwifT: yes, thanks :D
[23:09:42] <blueness> its nice to have the different security models around, even apparmor might be nice, but we don't have the manpower
[23:09:48] <Zorry> PeBenito should start mentor some of you and open a recrute bug
[23:10:02] <klondike> Agreed
[23:10:03] <blueness> SwifT, you were a developer no?
[23:10:10] <SwifT> I was yes
[23:10:19] <blueness> you retired?
[23:10:20] <klondike> then life hapened xD
[23:10:28] <SwifT> been one, retired due to timing issues, came back and then retired once more
[23:10:31] <SwifT> :)
[23:10:55] <SwifT> my life allows me to be very active for several months, but also to be inactive for several months
[23:11:34] <SwifT> made it difficult to be properly working on gentoo... bugs were then suddenly not seen for several months
[23:11:40] <Zorry> k
[23:13:11] <blueness> SwifT, we appreciate your help in whatever form.
[23:13:30] <SwifT> I know, and no worries, I'm not planning on disappearing anywhere soon :)
[23:13:39] <SwifT> (touches wood)
[23:14:26] <blueness> SwifT, i'll be happy to proxy for you anytime
[23:14:38] <blueness> (you almost made me believe in SELinux ... hehe)
[23:14:45] <SwifT> heh
[23:15:44] <SwifT> the real experts are people like Method and PeBenito here
[23:16:00] <SwifT> I'm just learning from whatever they say in #selinux (and dwalsh, dgrift, eparis and the like)
[23:16:15] <prometheanfire> I think selinux is a good alternitive for those of us that don't have the time for grsec :P
[23:16:26] <SwifT> you mean grsec's RBAC model?
[23:16:30] <blueness> yeah
[23:16:42] <SwifT> might be, i've never really looked at it
[23:16:47] <blueness> actually that's the misunderstanding: it isn't SELinux vs grsec
[23:16:55] <blueness> its selinux vs grsec/rbac
[23:17:02] <prometheanfire> :D
[23:17:08] <SwifT> true, all my selinux envs use grsec/pax
[23:17:16] <blueness> exactly
[23:17:17] <SwifT> sadly with the VIRTUALIZATION settings
[23:17:25] <Aleister> it might look good on my cv :-)
[23:17:35] <prometheanfire> Aleister: to use selinux?
[23:17:53] <Aleister> prometheanfire: yes if i ever was to degrade my self to sysadmin stuff :-)
[23:18:04] <prometheanfire> Aleister: oh thanks :P
[23:18:22] <prometheanfire> ya, I can say that selinux is more recognised in our world
[23:18:36] <Aleister> jokeing i just dosent find it that interesting :)
[23:19:06] <prometheanfire> so, is the meeting over?
[23:19:30] <SwifT> hmmm, getting late; c u tomorrow or so guys
[23:19:51] <Zorry> SwifT:  cu
[23:20:05] <Zorry> meeting done?
[23:20:17] <klondike> for me yes
[23:20:32] <Zorry> meeting done then

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Michael Orlitzky]

On 03/29/11 07:17, Magnus Granberg wrote:
> [22:55:55] <blueness> HP smart array, the CCISS driver is borked on 2.6.37 and maybe 2.6.38
> [22:56:07] <blueness> this is a blocker to stabilizing 2.6.37 right now
> [22:56:25] <prometheanfire> I thought that has been known for a while now though
> [22:56:29] <blueness> if i can't resolve it, i'll make a patch to revert the commits that changed how the pci bus is read on those systems
> [22:56:48] <blueness> prometheanfire, yes, but there's some confusion about it
> [22:57:10] <blueness> some people think it works, i've asked chainsaw to confirm before i file the bug, he has the same systems

I have a bunch of these too and would rather they not die after an
upgrade. Anything I can do to help?

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Anthony G. Basile]

On 03/29/2011 11:59 AM, Michael Orlitzky wrote:
> On 03/29/11 07:17, Magnus Granberg wrote:
>> [22:55:55] <blueness> HP smart array, the CCISS driver is borked on 2.6.37 and maybe 2.6.38
>> [22:56:07] <blueness> this is a blocker to stabilizing 2.6.37 right now
>> [22:56:25] <prometheanfire> I thought that has been known for a while now though
>> [22:56:29] <blueness> if i can't resolve it, i'll make a patch to revert the commits that changed how the pci bus is read on those systems
>> [22:56:48] <blueness> prometheanfire, yes, but there's some confusion about it
>> [22:57:10] <blueness> some people think it works, i've asked chainsaw to confirm before i file the bug, he has the same systems
> 
> I have a bunch of these too and would rather they not die after an
> upgrade. Anything I can do to help?

Yes.  I've been busy, but what we should do is test hardened 2.6.37-r7
and compare this to vanilla 2.6.37.4.  If it happens on both, then we
need to file a bug upstream while I revert the commits in .37 to the way
the pci bus is scanned for cciss.

This is popular hardware and I must solve this not only for both of us,
but others too.  I think Chainsaw has like 24 HP DL 385's.  I've asked
him to test but he hasn't gotten back to me.

-- 
Anthony G. Basile, Ph.D.
Gentoo Developer

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Michael Orlitzky]

On 03/29/2011 06:49 PM, Anthony G. Basile wrote:
> On 03/29/2011 11:59 AM, Michael Orlitzky wrote:
>> On 03/29/11 07:17, Magnus Granberg wrote:
>>> [22:55:55] <blueness> HP smart array, the CCISS driver is borked on 2.6.37 and maybe 2.6.38
>>> [22:56:07] <blueness> this is a blocker to stabilizing 2.6.37 right now
>>> [22:56:25] <prometheanfire> I thought that has been known for a while now though
>>> [22:56:29] <blueness> if i can't resolve it, i'll make a patch to revert the commits that changed how the pci bus is read on those systems
>>> [22:56:48] <blueness> prometheanfire, yes, but there's some confusion about it
>>> [22:57:10] <blueness> some people think it works, i've asked chainsaw to confirm before i file the bug, he has the same systems
>>
>> I have a bunch of these too and would rather they not die after an
>> upgrade. Anything I can do to help?
> 
> Yes.  I've been busy, but what we should do is test hardened 2.6.37-r7
> and compare this to vanilla 2.6.37.4.  If it happens on both, then we
> need to file a bug upstream while I revert the commits in .37 to the way
> the pci bus is scanned for cciss.
> 

Got it. Any particular type of borkage I should be looking for?

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Anthony G. Basile]

On 03/29/2011 09:11 PM, Michael Orlitzky wrote:
> On 03/29/2011 06:49 PM, Anthony G. Basile wrote:
>> On 03/29/2011 11:59 AM, Michael Orlitzky wrote:
>>> On 03/29/11 07:17, Magnus Granberg wrote:
>>>> [22:55:55] <blueness> HP smart array, the CCISS driver is borked on 2.6.37 and maybe 2.6.38
>>>> [22:56:07] <blueness> this is a blocker to stabilizing 2.6.37 right now
>>>> [22:56:25] <prometheanfire> I thought that has been known for a while now though
>>>> [22:56:29] <blueness> if i can't resolve it, i'll make a patch to revert the commits that changed how the pci bus is read on those systems
>>>> [22:56:48] <blueness> prometheanfire, yes, but there's some confusion about it
>>>> [22:57:10] <blueness> some people think it works, i've asked chainsaw to confirm before i file the bug, he has the same systems
>>>
>>> I have a bunch of these too and would rather they not die after an
>>> upgrade. Anything I can do to help?
>>
>> Yes.  I've been busy, but what we should do is test hardened 2.6.37-r7
>> and compare this to vanilla 2.6.37.4.  If it happens on both, then we
>> need to file a bug upstream while I revert the commits in .37 to the way
>> the pci bus is scanned for cciss.
>>
> 
> Got it. Any particular type of borkage I should be looking for?

Yes, the cciss array will not be recognized and as a result you get a
panic when root can't be found.  Not a very revealing bug.  We should
also make sure that I wasn't stupid and missed some new kernel option
that's needed, but I don't think so.  I know of 4 commits targetting
cciss which I suspect are the culprits.

-- 
Anthony G. Basile, Ph.D.
Gentoo Developer

[gentoo-hardened] BFS scheduler and GRSEC/PaX patches

[Anthony G. Basile]

Hi everyone,

I've merged together the BFS scheduler patch by Con Kolivas [1], and the
grsecurity patch[2].  There were some innocent mismatches and some not
so innocent.  I hacked up the BFS patch so that it applies *after* the
hardened-sources patches which includes the grsecurity patch.

You can get the hacked up BFS patch at

     http://dev.gentoo.org/~blueness/misc/hardened-bfs-2.6.38.patch

GPG: http://dev.gentoo.org/~blueness/misc/hardened-bfs-2.6.38.patch.asc

These are only available for 2.6.38.  To apply, first

	emerge =sys-kernel/hardened-sources-2.6.38

then cd into /usr/src/linux-2.6.38-hardened and

	patch -p 1 < /path-to/hardened-bfs-2.6.38.patch

Compile and enjoy(?)  WARNING: This is untested in the wild.  It works
on in a VM but should be considered unstable.  Let me know if your
system doesn't blow up.

For those of you unfamiliar, BFS scheduler reduces latency on desktop
systems, especially under heavy load.  So now you can run your desktop
fast and hard.  (I'm sure there's a bad pun in there somewhere :)

Refs

  [1] http://users.on.net/~ckolivas/kernel/
  [2] http://grsecurity.net/


-- 
Anthony G. Basile, Ph.D.
Gentoo Developer

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Michael Orlitzky]

On 03/30/11 07:56, Anthony G. Basile wrote:
> 
> Yes, the cciss array will not be recognized and as a result you get a
> panic when root can't be found.  Not a very revealing bug.  We should
> also make sure that I wasn't stupid and missed some new kernel option
> that's needed, but I don't think so.  I know of 4 commits targetting
> cciss which I suspect are the culprits.
> 

I haven't had any trouble on DL360 G2s; working on DL380 G5s next.

Re: [gentoo-hardened] Hardened meeting log 2011-03-23 20:00 UTC

[Anthony G. Basile]

On 04/01/2011 04:16 PM, Michael Orlitzky wrote:
> On 03/30/11 07:56, Anthony G. Basile wrote:
>>
>> Yes, the cciss array will not be recognized and as a result you get a
>> panic when root can't be found.  Not a very revealing bug.  We should
>> also make sure that I wasn't stupid and missed some new kernel option
>> that's needed, but I don't think so.  I know of 4 commits targetting
>> cciss which I suspect are the culprits.
>>
> 
> I haven't had any trouble on DL360 G2s; working on DL380 G5s next.

When you're done, email me your kernel config files.  Thanks :)

-- 
Anthony G. Basile, Ph.D.
Gentoo Developer