On 08/20/2014 04:06 AM, intrigeri wrote: > Hi, > Hi! > [re-adding pkg-aa-profiles-team@ into the loop, as I suspect that at > least Holger doesn't read the AppArmor ML yet.] > > Jamie Strandboge wrote (20 Aug 2014 03:46:57 GMT) : >> What package is being uploaded? Is this a separate apparmor policy package >> from >> the apparmor source package itself? > > Yes. It's called apparmor-profiles-extra. It's waiting in the NEW > queue, and we won't nag ftp-masters about it until the copyright and > license have been clarified upstream. > >> If so (and forgive me if I am misinterpreting-- I'd just like to make sure >> that >> this is discussed here), > > Well... it's been discussed here a bit a while ago already. > > I won't have time to reply in depth to the rest of your email before > DebConf, but I kindly invite you to re-read the email I've sent to > this very mailing-list 1.5 years ago: > > https://lists.ubuntu.com/archives/apparmor/2014-January/004876.html > > In there, I explained my rationale for going this way, and was seeking > for feedback. You replied to that email "I'd recommend that the > apparmor-profiles-extra package be a separate source package in > Debian". This is exactly what we've been working on since then. > Well, a year and a half is a long time, and I've had some time to think about this more.
> So, while the longer-term cross-distro collaboration plans can surely > be rediscussed, and are being rediscussed, I think that it's way too > late, in this Debian release cycle, to revisit the decision of > shipping a few additional profiles in a separate package in Jessie, as > opposed to adding them into the individual affected packages. > > Note that there are currently 4 profiles in the proposed package. > > * 2 of them (irssi, Pidgin) come straight from the apparmor-profiles > repo; the irssi one will likely be moved to the irssi package > before the Jessie freeze (yeah, we're also trying to go this way > when the maintainer is OK with it); > * 2 of them (Evince, tcpdump) come from individual Ubuntu packages. > > I want to add the Totem profile from apparmor-profiles before the > freeze. I think that's all what we're gonna ship in there in Jessie, > so if it's really problematic, then the problem is quite small, > localized, and easy to fix if we change strategy :) > Ok, with only 4-5 profiles in place, I don't see this as a major collaboration problem or anything and I agree this makes sense for Jessie. (also see my response to myself for how we can maybe do both the apparmor-profiles-extra package and pushing into the packages themselves) >> Ubuntu has already pushed policy into Debian packages somewhat, but there is >> more to be done. > > I *don't* want to throw stones at anyone, but I've seen very little > progress on this front since I'm involved in AppArmor. I think > a reality check is warranted, to make sure that we're speaking of the > same thing. Sure. If I wasn't clear, I am taking the position that Ubuntu can and should be doing better wrt to this. Historically, Debian took the position that it would not carry distro patches for AppArmor while Ubuntu would (eg, the compat patchset). This limited the collaboration in some ways for some time. Much more recently, specifically the last year and a half, AppArmor development has accelerated greatly and Ubuntu could in many ways be considered as the test bed for the work the AppArmor team wants to upstream (eg, dbus, signals, ptrace, and the upcoming anonymous and abstract socket mediation). This work required a *substantial* rewrite to the base labeling. Ubuntu and in particular the AppArmor developers have an overarching goal to push everything upstream and we have been upstreaming parts of this work where we could (eg, dbus and notice that the compat patchset that Ubuntu carries is considerably smaller than it used to be), however, due to the nature of the rewrite and how intertwined all the IPC work is (not to mention the namespace work that has been happening in parallel), much of this work has not been in upstreamable form since it wasn't complete (note, we've been writing it in an upstreamable way-- it just wasn't ready). Once the anonymous and abstract sockets work is completed, we should be able to upstream much of the aforementioned work. In the coming months we plan to improve systemd support and work on fine-grained network mediation which when accepted upstream should allow the compat patch to finally go away entirely. (We also plan to finish the stacked policy (aka namespace) work too.). All of this will allow us to align and more meaningfully collaborate on policy. I mention all this to provide some context-- the laser focus on this feature work in combination with Debian's kernel policies has unfortunately lead to less than optimal collaboration between Debian and Ubuntu. We can work together to change this though! :) > Here's the full list of profiles that landed from Ubuntu > in the Jessie release cycle, as far as I know: > > * bind9: I thinks this one truly was pushed by Ubuntu, thanks to the > package being collaboratively maintained between our two distros :) > * cups: I had the profiles (trivially) enabled in the Debian package > (Debian#735313); all it took was dropping a "if Ubuntu". > * mysql-5.5: I nagged people into removing the "if Ubuntu" bits > (Debian#736087), and then Ubuntu folks did most of the work. > * libvirt, mostly thanks to Felix Geyer for pushing/adapting things. > I'm now nagging the people who introduced the Ubuntu delta into > pushing it into Debian. > * LXC profiles from upstream (i.e. mostly Ubuntu): can't work in > a distro that doesn't patch the kernel heavily, as it relies on > dbus, signal, ptrace and mount rules. > * lightdm profiles from upstream (i.g. mostly Ubuntu): the Debian > maintainer initially included it as-is, but they didn't parse > since they relied on newer AppArmor features; I had to fix it. > > So, sure enough, stuff did come in, but that's not exactly what > I would call "Ubuntu pushing policy into Debian". I hope you can now > better see from what perspective I'm looking at these things :) > libvirt and LXC are probably the two most difficult examples for various reasons. Also, as you pointed out, our kernels are quite different which can be a pain point. That said, after going through the updates for dbus, signals, ptrace and now abstract and anonymous sockets, we can hide a lot of our differences in the abstractions (even now). Unfortunately I won't be at DebConf, but I know other members of the AppArmor team from Ubuntu are looking forward to meeting with all of you. > Anyway: thanks for your work, no bad feelings here. > None here either. My sincere hope (and plan!) is for the Ubuntu and Debian AppArmor teams to be able to move forward and make real progress on collaborating now that many of the hurdles are (coming) down. Thanks! -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
