=== wet-chan is now known as wet === ogra_ is now known as ogra === keffie_jayx_ is now known as effie_jayx === robbiew_ is now known as robbiew === MikeB is now known as technoviking === technoviking is now known as Technoviking === artir_ is now known as artir [18:01] jdstrand, mdeslaur: \o [18:02] hola! [18:03] o/ [18:03] okidoky [18:03] i'm doing community bits, just came off of triage [18:04] last week was filled with embargoed upstream issues. no idea why we got like 4 at once, but they're all in process now. [18:05] I'll be probably taking fetchmail and anything else I can find. the next kernel update is pending, so that will need attention too. [18:05] mdeslaur: you're up! [18:05] I'm on triage this week [18:05] and am working on apache2 [18:05] I just published gnome-screensaver [18:05] and I'll probably pick out something else [18:05] that's it [18:05] I'll go [18:06] * kees wonders when the g-ss love-in will end [18:06] hehe [18:06] hello [18:06] heya nxvl [18:06] last week I was on community. we published our first UCSN (Ubuntu Community Security Notice). more will need to happen with automation as we move forward [18:07] most of last week was spent on moin for the latest CVEs. I imagine this week will be the same. lots of commits to wade through. I have prelim patches for intrepid and higher [18:07] I've started writing patches for 1.5 (dapper and hardy), since upstream is not interested [18:08] jdstrand: yeah, that looks like quite a giant set of changes. yay for CSRF [18:08] * jdstrand nods [18:08] the code is quite different between the two, but the fix is easy enough to understand and write-- just need to get the fixes in all the right sports (which is the trick) [18:09] s/the two/1.5 and 1.7/ [18:09] * kees nods [18:09] beyond that, I am working on the ff apparmor profile and apparmor abstractions. I should be done with that today so people can be running that for a while [18:10] I also will be on vacation next week and the following monday, so you won't hear from me for a while :) [18:10] yay vacation! [18:10] \o/ [18:10] going anywhere fun, or is it a staycation? [18:11] cruise in the carribbean [18:11] niiiice [18:11] caribbean [18:11] yeah, it should be fun. I will not be available on irc though :P [18:11] that's it from me [18:11] set up DNS tunnelling before you go; I bet they have wifi. ;) [18:12] any other issues for the security team? [18:12] kees: well... I will have a laptop, but I don't want to get pinged ;) [18:12] yeah, bug #103010 [18:12] Launchpad bug 103010 in qemu-kvm "qemu no tun/tap networking" [Wishlist,Won't fix] https://launchpad.net/bugs/103010 [18:12] kirkland would like a statement from the security team [18:12] * kees reads [18:15] I need a lot more information about this bug before I can really say anything useful. [18:15] I would agree [18:15] kirkland: what's involved in setting up a tun/tap thing for kvm? [18:15] I can say that the recommended Ubuntu way to do virtualization is to use libvirt [18:15] i.e. is it possible to have kvm drop the cap after setting it up? [18:15] libvirt handles this on qemu's behelf in multiple ways [18:16] does it give a user arbitrary control over tun/tap devices (i.e. could they disrupt openvpn, etc) [18:16] kees: i don't know; haven't tried it [18:16] kees: but several people per release ask about this, and vte networking [18:16] vts? [18:16] er [18:16] vte? [18:16] kees: fat finger ... vde [18:17] libvdeplug2 - Virtual Distributed Ethernet - Plug library [18:17] * kees doesn't know what that is either. :) intreseting [18:17] i so cannot type today [18:17] * kirkland either [18:17] the kidsquid.com link is dead [18:18] kirkland: so, the issue is that people are trying to use kvm without running it as root. is the only issue networking? [18:19] kees: fyi-- qemu has a non-tun/tap way of doing networking as well, but it isn't nearly as useful [18:19] kees: i don't know, honestly; like jdstrand says, we have a recommended way of doing things, and these deviations from the norm are not ones i'm familiar with [18:20] kirkland: what are the recommended configurations? (is there a list/wiki somewhere?) [18:20] I don't think it's sane for a regular user without admin privileges to be able to play with networking settings [18:20] kees: https://help.ubuntu.com/community/KVM/Networking [18:21] mdeslaur: I think it depends on what qemu does. but, my feeling is that more than just creating this device is needed. setting up a tun/tap device with qemu used to require helper scripts, ifconfig, ... [18:22] is it me, or is that page a hodge-podge [18:22] it says KVM, and even has setcap, but then mentions libvirt and xml later [18:23] I thought there was an official page on all of this? [18:23] so, I don't like recommending "cap_net_admin=ep". I would prefer "cap_net_admin=ei" I think, and have a user with cap_net_admin=i, but I don't know how to set a user's inheritable caps [18:24] jdstrand: it's a mess [18:24] jdstrand: i cleaned it up some time ago, and it devolves down to a collection of hacks [18:24] kirkland: I thought you did work on the wiki-- but I thought it was somehwere else... the server guide? [18:25] jdstrand: it was all in the wiki [18:25] jdstrand: i split up the docs for kvm, virsh, virt-manager [18:25] https://help.ubuntu.com/9.10/serverguide/C/virtualization.html [18:25] jdstrand: cleaned that up [18:26] ok, here's what I'd like to see: [18:26] * jdstrand wonders if s/KVM/Virtualization/ would be more appropriate for the wiki, since it seems to cover kvm+libvirt [18:27] 1) qemu should drop caps when they're no longer needed [18:27] 2) documentation should be cleaned up a bit [18:27] 3) docs should include a "why" on this -- giving everyone on the system cap_net_admin via qemu is not safe [18:27] 4) bug should stay closed, with a pointer to the docs [18:27] kirkland: I'm thinking people edited KVM/Networking after you... [18:28] jdstrand: ack [18:28] The ultimate solution is to ship qemu with cap_net_admin=ei and document how to set a specific user to have cap_net_admin=i [18:28] kees: which of those todo's are for me? [18:28] kees: making sure qemu drops it soon... [18:28] kirkland: dunno; just talking out loud so far [18:29] the "1" could probably wait, though perhaps it needs to keep it forever -- I really don't know what it needs to be doing to the tun/tap [18:29] kees: the setcap commenter in the bug I think added the setcap in the wiki, fwiw [18:30] ligouri could speak to that [18:30] (the '1' bit) [18:31] kees: does setcap work on nfs? [18:31] kirkland: can you open a bug for #1, and update the docs for 2,3,4? [18:31] jdstrand: if xattr works on the remote fs, I think so yes. [18:31] I think it would then... [18:32] kirkland: I'm investigating how to do this "correctly", but it kind of requires fscaps support in dpkg, which isn't likely to happen until M. [18:32] * jdstrand was just thinking about the lontime problem of fscaps and filesystems [18:32] kees: i can open that bug soon-ish; doc's won't be updated for a good while [18:32] kees: probably not until we hit rc, when i hope i get a breath [18:33] kirkland: well, I can take 3 and 4 if you want. 2 isn't really needed, I guess. [18:33] kees: sounds good [18:37] kirkland: okay, I've done 3 and 4. [18:37] kirkland: you'll probably want to create a FAQ or something. [18:37] kees: thanks, i'll get the other one opened, and get a pointer from anthony [18:38] okay, anything else for the security team? [18:39] * kees takes that as a "no". meeting done. :) thanks everyone! [18:40] thanks everyone === yofel_ is now known as yofel