20080326

Meeting

Agenda for this meeting

  • Penetration Test Team Organization - emgent

    • CoC approval
    • private mailinglist status
    • switch name to ubuntu-whitehat

  • Ubuntu Security IRC organization room emgent

  • CVE review - KeesCook

  • To-Do List (Expanding our Roadmap) - JoeJaxx

  • MOTU-SWAT membership

  • SELinux progress - ChadSellers

  • SELinux GUI Utils - JoeJaxx

  • Hardening Wrapper testing - KeesCook

  • Next meeting time (not Wed - Fujitsu)

Notes

http://blackbird.kaarsemaker.net/mootbot/meeting/ubuntu-hardened.20080326_2001.html 

People Present:

   1. keescook
   2. emgent
   3. propagandist
   4. Fujitsu
   5. ScottK2
   6. andrea-bs
   7. jdstrand
   8. mathiaz
   9. SEJeff
  10. nxvl
  11. \sh
  12. takedown
  13. Kopfgeldjaeger
  14. michalski

Log

http://blackbird.kaarsemaker.net/mootbot/meeting/ubuntu-hardened.log.20080326_2001.html 

Started logging meeting in #ubuntu-hardened
[20:01:17] <keescook> [topic] agenda review
[20:02:02] <keescook> [link] https://wiki.ubuntu.com/SecurityTeam/Meeting
[20:02:25] <keescook> emgent asked that we re-arrange to put pentest first since he has conflicts later
[20:02:32] <keescook> is that a problem for anyone?
[20:03:08] <emgent> i think no :)
[20:03:16] <propagandist> nope ;o]
[20:03:30] * Fujitsu likes that idea, as he'll be less asleep for the later things.
[20:03:40] <keescook> [topic] pentest team
[20:04:03] <ScottK2> Is there an agenda for the meeting?
[20:04:15] <emgent> First of all, good evening:)
[20:04:20] <keescook> ScottK2: yeah, was sent just before you joined: https://wiki.ubuntu.com/SecurityTeam/Meeting
[20:04:27] <ScottK2> Thanks
[20:04:33] <keescook> np
[20:04:47] <emgent> Regarding ubuntu-pentest points would be put into question in an attempt to finally begin the project.
[20:05:02] <emgent> first: CoC approvation
[20:05:15] <emgent> [link] https://wiki.ubuntu.com/UbuntuPentest/GuidelinesDraft
[20:05:33] <emgent> kees and jamie wrote it, and for me big +1
[20:05:49] <emgent> some notes about it ?
[20:06:38] <keescook> jdstrand did a great job on it -- I view it as a "strict" CoC for situations where one runs the risk of breaking stuff
[20:06:39] <andrea-bs> +1 for me
[20:07:18] <emgent> ok cool.
[20:07:59] <keescook> if we need to make revisions in the future, we can do that. for now, we'll call it approved?
[20:08:09] <jdstrand> +1
[20:08:11] <ScottK2> Why mail the CoC acceptance?
[20:08:25] <ScottK2> Isn't accepted CoC on Launchpad sufficient?
[20:08:32] <emgent> for me approved.
[20:08:42] <keescook> ScottK2: this is the pentest CoC (not the ubuntu CoC)
[20:08:50] <ScottK2> Ah.
[20:08:50] <jdstrand> ScottK2: CoC on launchpad is different, and this isn't integrated in LP (yet)
[20:08:54] <ScottK2> Sorry. Got it.
[20:09:14] * ScottK2 suggests avoiding acronym overload.
[20:09:37] <keescook> PTCoC :)
[20:09:47] <emgent> hehe ok i will do in bzr branch too.
[20:10:03] <emgent> next?
[20:10:04] <andrea-bs> emgent: which branch?
[20:10:10] <emgent> well
[20:10:11] <keescook> the "mailing it" part leads to the next issue: private mailing list.
[20:10:26] <ScottK2> Nicely parallels the unfortunate word associations I get from pentest too. ;-)
[20:10:41] <emgent> first of mailinglist
[20:10:47] <keescook> we still don't have a private ml. in the meantime, should we just email other members of the u-pt team?
[20:10:48] <andrea-bs> emgent: found ;)
[20:11:01] <emgent> about anateater (reporting tool), i opened bzr branch https://code.edge.launchpad.net/~emgent/+junk/security-tools
[20:11:36] <mathiaz> keescook: have you looked in the LP mailing list ?
[20:11:41] <keescook> [link] https://code.edge.launchpad.net/~emgent/+junk/security-tools
[20:11:45] <keescook> mathiaz: yes, they cannot be private
[20:11:57] <mathiaz> keescook: ah..
[20:11:59] <emgent> it's a tool for write and send to launchpad pentest report
[20:12:13] <keescook> since pt may be discussing potentially undisclosed issues, we want don't want to leak stuff
[20:12:24] <emgent> i should complete integration with python-luanchpad-bugs, but i think to complete it shortly.
[20:12:35] <keescook> that was my next question. ;)
[20:12:36] <jdstrand> emgent: what does anateater do exactly?
[20:12:43] <emgent> anyway if someone like help to coding it, please mail me :)
[20:12:48] <jdstrand> sorry-- just read that
[20:13:13] <emgent> jdstrand: it's a simple python wizard for write pentest report and auto-send to launchpad complete report.
[20:13:27] <jdstrand> thanks
[20:13:32] <emgent> np :)
[20:13:55] <keescook> emgent: looks like a good template. we should probably adjust the code to use "coc" not "coc" followed by "k". :P
[20:14:14] <emgent> keescook: ok np :)
[20:14:32] <emgent> for private mailinglist some news?
[20:14:43] <keescook> 19:10 < keescook> we still don't have a private ml. in the meantime, should we just email other members of the u-pt team?
[20:14:44] <jdstrand> lol
[20:14:47] <emgent> it'snt good use open mailinglist for talk about infra bug
[20:15:03] <jdstrand> guess we know what emgent thinks of the CoC
[20:15:09] <jdstrand> ;)
[20:15:24] <emgent> ok, or i can install mailman in my server.
[20:15:26] <SEJeff> Is the Security team meeting here right now?
[20:15:33] <emgent> SEJeff: true. :)
[20:15:38] <keescook> SEJeff: yeah, we had a conflict with xubuntu meeting
[20:15:51] <SEJeff> Alright, thanks
[20:15:54] <SEJeff> Just listening
[20:16:25] <emgent> anyway i will post in ml when anateater is completed.
[20:17:03] <keescook> sounds good. I will continue to pester IS for the private ml. in the meantime, just send private emails to the members of the ubuntu-pentest team directly.
[20:17:25] <emgent> +1
[20:17:44] <emgent> about group name, we can think to switch it to ubuntu-whitehat
[20:17:59] <andrea-bs> no problem for me
[20:18:11] <keescook> +1 on whitehat name
[20:18:15] <Fujitsu> +1
[20:18:21] <ScottK2> +1 from me too.
[20:18:24] <jdstrand> either is fine for me, but I like the ubuntu-whitehat
[20:18:35] <emgent> ok i will change it.
[20:18:58] <emgent> next..
[20:19:10] <emgent> about IRC Room
[20:19:50] <emgent> i think that is good create #ubuntu-security (main room) and forward to it all branch (motu-swat, ubuntu-hardened, ubuntu-pentest)
[20:19:55] <keescook> \sh: can you email me an email address you'd like to use for the ubuntu-whitehat mailing list? (your email address is not public in LP)
[20:20:06] <nxvl> mm i had a channel confusion, i didn't see emgent's mail, sorry for been late
[20:20:16] <emgent> no the main is #ubuntu-hardned and #ubuntu-security forward to it.
[20:20:18] <nxvl> being*
[20:20:26] <\sh> keescook: sh@sourcecode.de
[20:20:38] <emgent> i think that is good follow main guidelines
[20:20:46] <keescook> emgent: I think we shouldn't forward ubuntu-hardened -- this has traditionally been for selinux discussions
[20:20:57] <emgent> that, main room (real room) all sub project only forward
[20:21:15] <keescook> I'd also like to not split motu-swat from the topics meant for ubuntu-security -- we're all in the same boat there
[20:21:30] <keescook> emgent: ah! I misunderstood which would be forwarded
[20:21:39] <emgent> yes
[20:21:47] <emgent> main #ubuntu-security
[20:22:02] <emgent> other all forwarded in.
[20:22:12] <keescook> it seems there are three distinct topics: fixing security issues, finding security issues, proactive security hardening
[20:22:31] <emgent> yep
[20:22:51] <takedown> excuse me, what is motu-swat? i didnt find anything on wiki
[20:23:04] <emgent> takedown: see launchpad
[20:23:08] <nxvl> takedown: https://edge.launchpad.net/~motu-swat
[20:23:11] <\sh> motu-swat is the universe section of ubuntu-security
[20:23:13] <keescook> takedown: sorry, motu-swat are the folks involved in doing universe-package security updates
[20:23:25] <emgent> https://edge.launchpad.net/~motu-swat
[20:23:32] <takedown> thank you
[20:23:32] <\sh> motu-swat reports to ubuntu-security members like kees or jd and they are reviewing the stuff
[20:23:53] <keescook> I've rather enjoyed having the 3 topics "merged" into on IRC channel, and playing devil's advocate, what is the reason to split up?
[20:24:57] <emgent> i think that is good use only one room because all team concern security.
[20:25:57] <emgent> And I think that the best thing would be to use # ubuntu-security as a main room, the sub-project only forwarded in
[20:26:05] <\sh> well, TBH i don't want to discuss security matters of LP or canonical infrastructure on a software-security channel .... i mean it's security, but some stuff doesn't belong to outsiders
[20:26:31] <takedown> i not a security team member, can i discuss too?
[20:26:33] <keescook> \sh: right, private disclosures should always be by private mailing list
[20:26:42] <emgent> yes
[20:27:09] <nxvl> yep, also all of them are security, but 3 diferent kinds of security, is like merging all the ubuntu IRC channels because all of them are ubuntu-related
[20:27:18] <\sh> keescook: if this will be the policy, I'm +1 for the #ubuntu-security channel for all matters != private disclosures
[20:27:19] <nxvl> takedown: yep
[20:27:34] <emgent> \sh +1
[20:27:54] <SEJeff> \sh So what happens to #ubuntu-hardened? Will it be relegated to proactive stuff or forward to ubuntu-security?
[20:28:08] <emgent> yes
[20:28:12] <keescook> I'd like to confirm with the original creators of the ubuntu-hardened irc channel (and mailing list) if they're okay with the switch
[20:28:22] <SEJeff> Well the original creator is trulux
[20:28:26] <jdstrand> pragmatically speaking, do we really have enough chatter to warrant all the channels?
[20:28:31] <emgent> now if you try to join #ubuntu-security you will be forwarded in #ubuntu-hardened
[20:28:34] <SEJeff> He is no longer involved in this project anymore
[20:28:44] <jdstrand> IIUC, didn't we breathe new life into #ubuntu-hardened
[20:28:48] <keescook> jdstrand: we're basically only talking about renaming -hardened to -security
[20:28:50] <\sh> SEJeff: well, -hardened sounds more for discussion as SElinux or apparmor stuff, related to implementations on core level in *Ubuntu
[20:29:01] <SEJeff> \sh ok good. Thats what I was hoping
[20:29:31] <SEJeff> jdstrand Yes, christer edwards got jono to help control access to the group and trulux gave me o on this channel
[20:29:48] <SEJeff> we got it back under control with a bit of help from jono
[20:29:56] <keescook> I'd like to get input from Zelut about the name change -- he was who had everyone join u-h after the last UDS
[20:29:58] <nxvl> and users having security problems, or looking for help on security will ask in channel where security issues development is discussed?
[20:30:40] <keescook> SEJeff: what are your thoughts on it? would you prefer that proactive work be discussed separately?
[20:31:39] <SEJeff> keescook: Ideally, yes. Splitting things up a bit is easier to manage from my standpoint
[20:31:54] <SEJeff> Just pinged Zelut on jabber. Lets see if he joins
[20:32:35] <keescook> [action] keescook to take naming issue (-hardened vs -security) for IRC to mailing list for further input
[20:33:15] <emgent> keescook: remember to activate forward
[20:33:34] <keescook> yup
[20:33:42] <emgent> cool, it's all for me :)
[20:33:57] <keescook> [topic] CVE review
[20:34:31] <keescook> I have been working to create an "exported" view of CVEs in ubuntu (in the ubuntu-cve-tracker bzr tree), though it is still not finished.
[20:34:55] <keescook> Fujitsu has been doing a great job hammering away at CVE triage in universe.
[20:35:14] <\sh> ah CVE tracker...favorite topic...
[20:35:26] <keescook> any other issues people want to discuss in this area?
[20:35:36] <Fujitsu> I believe we now have a list of what actually needs to be fixed in Hardy, rather than what needs to be checked for vulnerability in Hardy.
[20:35:49] <\sh> what do you think about a public website for public accessible CVE issues in Ubuntu...so we can find people working on those?
[20:35:56] <jdstrand> I hope to dive into the html export stuff soon
[20:36:02] <jdstrand> CSS, etc
[20:36:05] <keescook> \sh: yup, that's what I've been testing.
[20:36:10] <emgent> :)
[20:36:36] <keescook> I had wanted it ready for this meeting, but it still needs a little more love
[20:36:48] <jdstrand> Fujitsu's been doing a lot of triaging of old stuff- big thanks!
[20:36:51] <keescook> there is a "TODO" file in ubuntu-cve-tracker that details that work
[20:37:09] <Fujitsu> If only LP was up to the task that u-c-t has been created to perform :(
[20:37:17] * jdstrand nods
[20:37:20] <emgent> true
[20:37:26] <keescook> (har har, my pestering of IS paid off: the ubuntu-pentest mailing list was just created)
[20:37:31] <Fujitsu> jdstrand: No problem, it had to be done at some point.
[20:37:48] <Kopfgeldjaeger> ufw-developer here?
[20:37:54] <keescook> Fujitsu: yeah. though now we have a pretty extensive requirement list for when there is coding-power ready to implement it.
[20:38:07] <Fujitsu> Kopfgeldjaeger: We're in the middle of a meeting.
[20:38:10] <SEJeff> keescook: If you want some nifty table sorting and column resizing, I volunteer to add it to your cve tracker with tablekit
[20:38:12] <jdstrand> Kopfgeldjaeger: yes, can you take it to #ubuntu-devel-- there is a meeting now
[20:38:20] <Kopfgeldjaeger> ok, thanx
[20:38:44] <jdstrand> SEJeff: I am interested in that
[20:38:51] <keescook> SEJeff: that'd be nice
[20:38:58] * jdstrand was just thinking of that hte other day
[20:39:06] <keescook> right now things are kind of scripts-bolted-to-scripts
[20:39:19] <SEJeff> keescook, jdstrand email me a URL and I'll send a diff. Can you see my email on lp?
[20:39:20] <keescook> I did add a global Makefile though
[20:40:02] <jdstrand> SEJeff: yes
[20:40:23] <keescook> joejaxx: are you here to discuss items for the TODO list?
[20:41:12] <SEJeff> Sorry to spam, but can someone add me to ubuntu-{pentest,whitehat}? Time to work on this stuff a bit more
[20:42:06] <keescook> [topic] TODO / Roadmap
[20:42:22] <keescook> [link] https://wiki.ubuntu.com/SecurityTeam/Roadmap
[20:42:26] <takedown> When CVE tracker will be done, someone must modify apt-listbugs package to grab from this. Just idea about cve
[20:42:45] <keescook> there are 2 areas I'd really like to get some volunteers for: creating the FAQ and KnowledgeBase wiki pages.
[20:42:55] <keescook> does anyone have some time for that?
[20:44:15] <\sh> ha...time is an issue for me now :(
[20:45:38] <keescook> any items we should add to the FAQ list?
[20:45:50] <takedown> What should be in knowledgebase? Articles for securing ubuntu, tweaking daemons or what?
[20:45:50] <propagandist> heh, i was just going to ask that
[20:46:37] <nxvl> i have some free time to write the FAQ, i just need material for putting in there
[20:46:39] <keescook> takedown: that could work in a "links" section maybe. It seems like the KB would be for longer reference material, and that the FAQ might point into it for answers.
[20:46:58] <mathiaz> takedown: nope - The KB is about how the security is team is working
[20:47:05] <nxvl> since i have no idea what should be in there
[20:47:29] <keescook> mathiaz: can you explain a bit more about KB? what did you do for the server team?
[20:47:33] <mathiaz> things like when meeting are done, which ressources are available, how is the cve tracker used and what it does
[20:48:03] <mathiaz> the kb is about documenting about the tools/workflows that the security team uses to accomplish it's work
[20:48:31] <mathiaz> so for example, in the server team KB, there is a description on what should be done to publish the minutes of the meetings
[20:48:37] <keescook> mathiaz: ah-ha, okay. so ubuntu-cve-tracker would go in there, as well as LP links, etc
[20:48:51] <mathiaz> for the security team, explain how the bug workflow is done
[20:48:56] <keescook> mathiaz: were would you recommend things like "policy" go?
[20:48:57] <mathiaz> if you're using specific tags
[20:49:07] <mathiaz> keescook: KB is a good start
[20:49:21] <mathiaz> keescook: a section there - once it expands, you can add another wiki page
[20:49:33] <keescook> mathiaz: I mean like the "no open ports by default" policy and details about it?
[20:49:36] <keescook> okay
[20:49:43] <\sh> hmmm.."policy" sounds here more like a description and explanation of normal security admin tasks in a company ;)
[20:49:46] <mathiaz> keescook: that's the technical bits
[20:49:49] <jdstrand> keescook: are any of the things on that FAQ already covered by ubotu?
[20:49:58] <mathiaz> keescook: I don't think it should be in the KB
[20:50:01] <jdstrand> and if not, they probably should be
[20:50:18] <mathiaz> keescook: it has nothing to do with the security team - it's a feature of ubuntu, the product
[20:50:53] <mathiaz> the KB is about documenting how the team is working, not the outcome of its work
[20:52:03] <keescook> mathiaz: true, but we get questions about it, and there needs to be documentation for it somewhere.
[20:52:27] <jdstrand> we could link from here to the appropriate page
[20:52:37] * keescook nods
[20:52:55] <mathiaz> keescook: yes - so that may be good item for a FAQ
[20:53:20] <keescook> okay, well, if people do have any free time, please see if you can create the FAQ or KB areas and get them started. :)
[20:53:29] <keescook> [topic] motu-swat membership
[20:53:46] <keescook> do we have any pending members, and how should this be handled?
[20:54:13] <emgent> uhm
[20:54:31] <emgent> i think no
[20:54:46] <emgent> only one membership in ubuntu-whitehat: SEJeff
[20:55:00] <\sh> depends on the status of this team
[20:55:00] <keescook> correct, https://edge.launchpad.net/~motu-swat/+members shows no one pending. :)
[20:55:18] <\sh> right now it's just for some motus to know about security bugs in universe packages...there
[20:55:33] <\sh> Fujitsu: correct me if I'm wrong on this one
[20:55:42] * ScottK2 cheers more bugmail.
[20:55:55] <keescook> heh
[20:56:00] <emgent> :)
[20:56:43] <keescook> it's listed as a Moderated Team, so we should probably document how approval happens.
[20:56:47] <nxvl> emgent: where is ubuntu-whitehat?
[20:56:51] <keescook> who can do that?
[20:57:08] <Fujitsu> \sh: I'm not really sure of the purpose... primarily bugmail at the moment, I think.
[20:57:11] <emgent> nxvl: read logs :)
[20:57:27] <emgent> nxvl: new ubuntu-pentest name
[20:57:30] <Fujitsu> emgent:
[20:57:31] <Fujitsu> 06:56:39 < barry> are we killing the mailing list or renaming that too?
[20:57:33] <keescook> emgent: oh, I though everyone agreed to ubuntu-pentest => ubuntu-whitehat renaming?
[20:57:45] <emgent> Fujitsu: renaming
[20:57:54] <Fujitsu> emgent: Don't we have the new one for that, though?
[20:58:04] <keescook> the "ubuntu-pentest" private mailing list we can't rename.
[20:58:19] <\sh> Fujitsu: I think we could use the team to gather some new people working on security (for universe) and after some time, they get approved, and jd and kees know who we trust ;)
[20:58:23] * jdstrand thinks it's nice how we renamed the group right when we got the ml
[20:58:28] <emgent> keescook: now it isnt private
[20:58:47] <keescook> \sh: I'm fine with that. :) "approved by an existing admin"
[20:58:48] <nxvl> emgent: yes, that i knew, but are you talking about the LP group, mailing list or IRC channel?
[20:58:59] <emgent> launchpad group
[20:59:19] <Fujitsu> \sh: That works.
[20:59:30] <Fujitsu> keescook: Sounds good.
[20:59:58] <keescook> [agreed] motu-swat membership: "approved by an existing admin"
[21:00:00] <\sh> Fujitsu: ha...let me think about more teams :>
[21:00:27] <emgent> i have to go, i will read the log. see you later people
[21:00:27] <keescook> okay... confusion subsiding (I hope)
[21:00:34] <keescook> bye emgent, thanks!
[21:00:35] <emgent> thanks for all.
[21:00:36] * SEJeff waves to emgent
[21:00:38] <Fujitsu> Bye emgent.
[21:00:39] <jdstrand> bye emgent!
[21:00:43] <keescook> [topic] SELinux update
[21:00:55] <keescook> okay, how goes things on the selinux front?
[21:00:56] <propagandist> heyya ;o]
[21:01:28] <propagandist> Updated packages to devel release in my tree. I am currently reviewing Debian and Fedora's packages for any patches that we may be missing. After this I will put up ffe requests.
[21:01:46] <ScottK2> I think we need to revisit forking from Debian on SE Linux
[21:02:16] <propagandist> Manoj and I are talking about this
[21:02:23] <keescook> \o/
[21:02:29] <ScottK2> OK.
[21:03:02] <propagandist> I do want to get them synced up again.
[21:03:03] <ScottK2> Last I heard at UDS we were going to be based off of Debian and so I was a little suprised to find him so upset.
[21:03:30] <michalski> question---> server team meeting in here or #ubuntu-meeting
[21:03:46] <propagandist> Manoj was mia for a time. Unfortunately that time coincided with the Ubuntu work.
[21:03:54] <keescook> michalski: afaik, #ubuntu-meeting (in an hour, after xubuntu is done)
[21:04:05] <michalski> wilco
[21:04:09] <ScottK2> That didn't require a fork
[21:04:28] <ScottK2> I can understand why you did it. His packages are rather opaque
[21:04:38] <propagandist> We didn't know at time if he was coming back or not. CDBS looked easier to maintain.
[21:04:44] <ScottK2> Right.
[21:05:08] <ScottK2> For Hardy if we can just undo the package renaming, we can resync the contents for Ibex
[21:05:45] <ScottK2> If we don't do that, we'll have to maintain transitional packages until the next LTS. I'd prefer to avoid that.
[21:06:05] <keescook> it's only setools that needs the renaming, correct?
[21:06:10] <propagandist> I think it will be more than just undoing the package renaming.
[21:06:15] <ScottK2> AFAIK yes.
[21:06:31] <ScottK2> propagandist: Yes, but not necessarily until Ibex.
[21:06:54] <keescook> can we safely sync setools from debian unstable for hardy?
[21:07:18] <propagandist> ScottK2: sorry I don't understand, what is Ibex?
[21:07:23] <ScottK2> Hardy +1
[21:07:26] <keescook> the only ubuntu-specific packaging (beyond setools) was the arrangement of policies and the creation of "selinux" pkg.
[21:07:29] <keescook> intrepid.
[21:07:39] <ScottK2> keescook: He's planning on an upload this weekend
[21:07:55] <ScottK2> Ibex is less typing.
[21:08:03] <propagandist> ah i see
[21:09:16] <propagandist> ScottK2: have you tested his setools package with the rest of the ubuntu packages?
[21:09:25] <ScottK2> propagandist: No. I haven't seen it yet.
[21:09:45] <ScottK2> My interest here is Debian/Ubuntu relations. I'm not deeply interested in SE Linux myself.
[21:10:17] <SEJeff> Ask Russel Coker for Debian SELinux
[21:10:59] <propagandist> If changing setools to the debian package doesn't break anything, then +1
[21:11:02] <ScottK2> He's got nothing to do with setools http://packages.qa.debian.org/s/setools.html
[21:11:33] <propagandist> but the upstream maintainers provide packaging of their own now (as they do for Fedora also)
[21:11:40] <SEJeff> ScottK2 Oh right. But he is one of the main SELinux guys for Debian. /me lurks now
[21:12:06] <ScottK2> propagandist: I've never seen an upstream provide good distro specific packaging.
[21:12:57] <ScottK2> I haven't looked at these, but I'd put my trust in Debian.
[21:13:21] <propagandist> I will look at using the debian setools package
[21:13:52] <ScottK2> propagandist: At least get the package names consistent, please.
[21:14:07] <ScottK2> I know this is more effort for you, but it'll pay off in the long run.
[21:14:10] <propagandist> Just to make sure, this is only an setools problem? This will not be a problem for updating the rest of the selinux packages to their upstream devel release?
[21:14:15] <nxvl> it isn't a matter of trust, it's a matter of the best to do for good maintenace, and if debian packages aren't the best, we need to patch them, not replace
[21:14:34] <Fujitsu> Why would Debian packages not be the best?
[21:14:41] <propagandist> nxvl: i agree
[21:15:01] <Fujitsu> Oh, I see what you mean now.
[21:15:05] * Fujitsu agrees with nxvl.
[21:15:08] <ScottK2> My immediate concern is to get consistent namespace. AFAIK it only affects setools, but I'm not sure.
[21:15:23] <propagandist> The namespace itself should be fixed with 3.3.4
[21:15:45] <propagandist> 3.3.4 added the transitional packages that were asked for
[21:16:12] <ScottK2> But we don't want just transitional packages unless Debian is going to rename too.
[21:16:25] <ScottK2> We want to be using the same binary package names that Debian is using.
[21:16:40] <propagandist> ScottK2: agreed, i will look at just using their packages
[21:16:56] <nxvl> ScottK2: and if it is possible the same source packages too
[21:17:07] <ScottK2> nxvl: Yes. We already have that, IIRC.
[21:17:22] <ScottK2> Err names anyway, but content would be good too.
[21:17:51] <keescook> still, I'm quite happy with how SELinux has turned out in hardy. Manoj was MIA at a bad time, is all.
[21:18:12] <nxvl> MIA?
[21:18:14] <ScottK2> Understand. We just need to fix it as best we can now.
[21:18:21] * keescook nods
[21:18:23] <ScottK2> Missing In Action.
[21:18:31] * nxvl HUGS ScottK2
[21:18:37] <ScottK2> He got quite busy with $WORK and had to give up Debian for a while.
[21:19:34] <keescook> joejaxx: here?
[21:19:45] <propagandist> on a different topic: LP: #203433
[21:19:49] <keescook> we'll have to skip the gui tools topic...
[21:19:58] <propagandist> cp does not preserve the security contexts
[21:20:33] <propagandist> if someone else can weigh in on what the best fix is that would help
[21:21:03] * keescook doesn't have an opinion on this.
[21:21:16] <keescook> in the interest of least-surprise, how do RH and Debian handle it?
[21:23:51] <keescook> propagandist: also, there was some discussion about last-minute userspace/kernel updates? what was that about?
[21:24:04] <\sh> .oO(they install X during boot time and just don't care about security contexts ;))
[21:24:06] <propagandist> I didn't think that the debian cp was different. I looked at the RH patch a while ago, but i've forgotten right now what exactly it did :o(
[21:25:14] <propagandist> keescook: ah, there is a problem with restarting services because unconfined isn't allowed system_r. We're working on a policy patch to fix that up, but the best solution is to add support for user transitions (which was what Method was talking about)
[21:25:22] <keescook> well, if it is decided it needs to be fixed, I think it's a reasonable thing to SRU -- it's a small change, easy to test, etc.
[21:25:31] <propagandist> I think that its best that we don't try to do that right now and just stick with th epolicy changes.
[21:25:47] <keescook> propagandist: okay, sounds good.
[21:26:11] <keescook> shall we move on?
[21:26:17] <propagandist> +1
[21:26:20] <keescook> [topic] hardening wrapper testing
[21:26:50] <keescook> nothing too new on this front. it seems some maintainers in Debian have started using it directly, which is nice.
[21:26:55] <\sh> can we enable it for ibex by default?
[21:27:09] <keescook> \sh: that is the plan -- I've been promised that it will happen
[21:27:44] <keescook> \sh: and I'm keeping a close eye on infinity, who has been building up the buildds for ibex. :)
[21:28:18] <keescook> (debian's use uncovered some issues, but they were entirely related to archs ubuntu doesn't have: s390, m68k, etc)
[21:28:26] <jdstrand> yay
[21:28:41] <jdstrand> (not on the issues, mind)
[21:28:45] <keescook> heh
[21:29:01] <\sh> keescook: sounds promising...I just read about it, and we should focus on that
[21:29:11] <keescook> I was reading an mplayer exploit on milw0rm. it starts with "if randomization is disabled..." :)
[21:29:59] <keescook> there will certainly be some packages that explode with all the options enabled.
[21:30:12] <Fujitsu> ... which is why one does it early and not in an LTS.
[21:30:25] <Fujitsu> Unlike what has been done with toolchain changes in Hardy.
[21:30:28] <keescook> so we'll need to educate u-core-dev and u-dev about the issues, how to distinguish them, and how to fix them.
[21:31:11] * ScottK2 thinks it'd be more fun to wait unti the beta to do it.
[21:31:27] <\sh> keescook: well, more fun will it be to educate upstream about those issues ;)
[21:32:47] * \sh remembers the time when we were fixing amd64 issues..and educate upstream that int doesn't have the very same size as long on 64bit
[21:33:17] * keescook cries
[21:33:40] <keescook> right -- upstreams doing it would be nice, but some of the issues are pretty distro and arch specific.
[21:34:00] <keescook> (for note, since I have commit access to inkscape, it's been all but PIE for many months now...)
[21:34:16] <keescook> okay, any other topics?
[21:34:39] <\sh> .oO(improve inkscape to be a very good visio replacement?) ;)
[21:35:20] <keescook> \sh: send a patch! ;)
[21:35:30] <keescook> [topic] next meeting time
[21:35:49] <keescook> Fujitsu: you had mentioned that Wed is especially painful for you. can you recommend a different time/day?
[21:36:34] <jdstrand> oh, I wanted to mention something
[21:36:48] <keescook> jdstrand: go for it
[21:36:49] <Fujitsu> keescook: Any day but Tue/Wed is OK at this time, but an hour later would be much better.
[21:36:54] <jdstrand> regarding testing of debdiffs
[21:37:21] <\sh> Fujitsu: thu 8pm UTC is for me much better, too :)
[21:37:24] <jdstrand> I wanted to reiterate the importance of testing patches on every release that a debdiff is supplied for when fixing a CVE
[21:37:51] <jdstrand> the code path of the patch must be exercised, otherwise there is no way to no of regressions
[21:38:04] <jdstrand> s/to no/to know/
[21:38:09] <keescook> jdstrand: yes, thanks for the reminder.
[21:38:19] <keescook> great time to promote the qa-regression-testing bzr tree
[21:38:21] * Fujitsu has been testing more thoroughly since the regression in December.
[21:38:25] <\sh> jdstrand: code path? you mean from where the patch comes?
[21:38:36] <jdstrand> I'd also mention that many packages have a build test suite internally, often as easy as 'make check'
[21:38:39] <keescook> I wrote tests all day yesterday to handle things like the ruby1.8 update, dovecot updates, libnet-dns-perl update, etc.
[21:38:56] <keescook> it's really nice to be able to "prove" that a given debdiff is safe.
[21:39:02] <\sh> that reminds me of the missing ruby* debdiffs for dapper
[21:39:03] <jdstrand> \sh: if the patch modifies foo(), foo() needs to be exercised in testing
[21:39:05] <Fujitsu> keescook: Very nice.
[21:39:24] <\sh> jdstrand: ah...test cases :)
[21:39:32] <keescook> meeting time> I propose Thu Apr 10, 20UTC ?
[21:39:39] <jdstrand> we have qa-regression-testing in LP that has some stuff to help in this regard
[21:39:49] <jdstrand> some scripts, some build notes, some tips and checklists
[21:40:01] <jdstrand> and additions are *always* welcome :)
[21:40:01] <propagandist> keescook: +1
[21:40:26] <nxvl> +1
[21:40:31] <Fujitsu> keescook: +1
[21:40:42] <jdstrand> keescook: +1
[21:40:53] <\sh> jdstrand: I would be glad to know how you test e.g. the wireshark stuff.. sometimes I have luck and there is a stream of packets attached to the bug reports at wireshark.org, but sometimes it's totally not working to reproduce the exploit :(
[21:40:57] <\sh> keescook: +1
[21:41:25] <keescook> [topic] debdiff testing
[21:41:31] <\sh> jdstrand: even reading bugtraq and other things ;)
[21:41:38] <jdstrand> \sh: I don't have specifics on wireshark-- does it have a builtin test suite?
[21:41:51] <keescook> \sh: yeah, getting the "infrastructure" built to do a test is by far the hardest part
[21:42:01] <\sh> jdstrand: I don't think so :)
[21:42:06] <jdstrand> bummer
[21:42:12] <keescook> for IMAP testing, I actually configure an entire dovecot server and plop email down for it (testlib_dovecot.py)
[21:42:35] <\sh> jdstrand: testing "malformed mp3s which were produced by some mad brain and let crash wireshark" is hard to reproduce or hard to setup ;)
[21:42:42] <jdstrand> similar things happen with openldap
[21:42:52] <keescook> for wireshark, for example, I'd find a tool that could re-send network traffic (nemesis?) and bolt that on to a given test.
[21:43:38] <keescook> obviously, some times there are no reproducers. in which case, it's nice to figure out how to get a PoC, but generally if there is a PoC available, we should attempt to use it for testing.
[21:43:41] <\sh> keescook: the problem is not to re-send network traffic (good that you can load wireshark packet streams), but if there is no test-data to load...it's hard to
[21:43:43] <jdstrand> (openldap was in response to keescook)
[21:43:50] <\sh> because I don't know what a malformed mp3 file is ;)
[21:44:15] <jdstrand> \sh: there will always be these kinds of situations-- where there is a theoretical vuln or no PoC
[21:44:16] <\sh> keescook: agreed :)
[21:44:19] <keescook> \sh: yes, right. that's true -- in that case, even sending "good" traffic is nice too.
[21:44:56] <\sh> and I have another topic for this...again wireshark as an example..
[21:45:27] <jdstrand> \sh: but running a regression test or build test suite can help
[21:45:35] <\sh> when the upstream devs are rewriting complete sources....how do we proceed with issues, where it's exploitable, but the patch we get is for the new source
[21:45:57] <keescook> \sh: that is by far the hardest situation to deal with.
[21:45:59] <jdstrand> \sh: that is very hard
[21:45:59] <\sh> (as seen for wireshark and the snmp dissector)
[21:46:02] <Fujitsu> \sh: You hit upstream with something very hard and painful.
[21:46:15] <jdstrand> latest mysql took a *long* time to publish for just that reason
[21:46:21] <\sh> and we have luck that the gutsy version in our repos are not vulnerable
[21:46:36] <jdstrand> SRU is sometimes the answer, sometimes not
[21:46:37] <\sh> s/are/is/
[21:46:40] <Fujitsu> keescook: I see all those Java CVEs are now fixed in Hardy!
[21:46:53] <keescook> Fujitsu: yeah, I read your comments, and then saw doko's upload. :)
[21:47:06] <keescook> \sh: I think this makes an excellent KB item.
[21:47:18] <\sh> jdstrand: yeah...but e.g. the dapper version is totally outdated...so even an SRU won't help...just backports
[21:47:38] * jdstrand nods
[21:47:38] <keescook> for microrelease updates (which wireshark doesn't do, but postgres, firefox do) we have an SRU process
[21:47:47] <\sh> jdstrand: only regarding the API changes they introduced between dapper and edgy
[21:48:05] <jdstrand> hence the 'sometimes not'
[21:48:08] <jdstrand> :/
[21:48:28] <keescook> I think we need to just get what we can do done -- we'll never be perfect.
[21:49:01] <\sh> does "perfect" means "god alike"? ;)
[21:49:15] <keescook> in the case of drastically aging stuff, perhaps do -backports when SRU can't be done.
[21:49:33] <keescook> this kind of decision-process is what I was thinking we could put in the KB.
[21:49:55] <ScottK2> Clamav being an example
[21:50:00] <jdstrand> ScottK2: exactly
[21:50:06] <jdstrand> I was just thinking of that
[21:50:22] <\sh> keescook: yeah, that's how we are working ... we ask each time, we stumble upon those problems, what way we should go
[21:50:30] <Fujitsu> ClamAV is in dapper-updates now, isn't it?"
[21:50:41] <ScottK2> Yes
[21:50:43] <jdstrand> Fujitsu: yep, cause of very careful testing :)
[21:50:46] <\sh> ScottK2: well, we need to document it, and tell the users to enable -backports for those stuff
[21:50:47] <Fujitsu> Very good.
[21:50:58] <jdstrand> (not be me)
[21:51:16] <keescook> (there is a big clamav test in qa-regression-testing, though it doesn't test ABI sanity)
[21:51:17] <ScottK2> \sh: That or test it enough to convince pitti to copy it into updates.
[21:51:40] <jdstrand> point I was trying to make is a smoke test or worst yet a successful compile is not enough
[21:51:58] <ScottK2> And in fact I missed that one interface had been dropped and broke somebodies customized package.
[21:52:25] <ScottK2> Which is why we now have python-pyclamd to replace the bit that python-clamav dropped.
[21:52:38] <keescook> heh, nice
[21:53:13] <\sh> ScottK2: that's why you don't install things on production machines without testing it before
[21:53:27] <ScottK2> Yes, but -updates is supposed to be safe.
[21:53:34] <\sh> ScottK2: even then :)
[21:53:41] <ScottK2> Agreed.
[21:53:45] <\sh> ScottK2: it was a hard time to learn exactly that
[21:53:58] <\sh> after breaking 50 boxes
[21:54:33] <keescook> okay, another excellent meeting drawing to a close. I'll update the wiki with the next meeting time, and tweak the agenda.
[21:54:43] <Fujitsu> Thanks keescook.
[21:54:51] <jdstrand> thanks keescook!
[21:54:51] <\sh> keescook: thx :)
[21:54:53] <ScottK2> All in all, I know of that update causing problems for two people and it retired ~20 CVEs. I'd call it a good trade.
[21:55:10] <keescook> thank you all! I'm really happy to have so many people working on all aspects of security in ubuntu. thanks for coming. :)
[21:55:22] <keescook> #endmeeting
Meeting ended.

MeetingLogs/Security/20080326 (last edited 2008-08-06 16:41:31 by localhost)