Hi, (I'll drop the Cc: to debian-derivatives in my next email, unless folks express interest.)
Kees Cook wrote (14 Feb 2012 19:59:45 GMT) : > Ubuntu's evince and isc-dhcp-client profiles are very well tested at > this point. I think it should be easy to move those into Debian if > they're not there already. Right, I'm glad I've not encountered any single problem with these profiles. I'd like to thank everyone involved in their initial development, adaptation to Ubuntu, and testing. >> 2. some software that is particularly important in the context of >> Tails [0]: I'm mainly thinking of Tor, but GnuPG and icedove also >> come to mind. > What did you have in mind for GPG? Protecting it from itself is a bit > tricky. :) I don't intend to protect GnuPG from itself. By design, GnuPG handles much untrusted data. I would like to protect the rest of the system from GnuPG. Does it make sense, or did I miss something obvious? (I'm pretty new in this landscape, so it would not surprise me if I had.) >> 3. some low-hanging fruits from Ubuntu's "Supported profiles in main" >> list [1] that, I guess, you know very well: apache2, libvirt. >> >> [0] https://tails.boum.org/ >> [1] https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles > I think just encouraging all the maintainers to pull in the Ubuntu > patches for AppArmor profiles is the best way to start. > Several packages have already done this (e.g. bind9). I think this will be totally relevant at some point, but I beg to disagree this is a good way to start. Here's why. Very well tested in Ubuntu is great, but sometimes is not always enough to be usable at all in Debian. The gdm vs. gdm3 bug in the X abstraction I've just reported against the apparmor package (sorry, being offline, I've no bug number yet) indicates that even trivial Debian-specific problems, in very common apparmor abstractions, were not detected yet. Therefore, I think at least some basic manual testing is due before we ask a Debian maintainer to ship any profile with their packages. I can see the interest of getting a bunch of profiles ASAP into Debian, but frankly, I would not want to be the one nagging a package maintainer a second time to include a fixed AppArmor profile, after having nagged them a first time to include an *untested* AppArmor profile, that would have appeared obviously broken to anyone who would have basically tested it in Debian. Yeah, I'm describing the catastrophic scenario here. I just don't want maintainers' first encounter with AppArmor to look like it's a painful thing pushed by careless people: instead, I would like us to do the bare minimum so that it is painless to them :) >> To get things started, I have started using some of the profiles >> shipped in the apparmor-profiles packages; but none of the > There's documentation in the Ubuntu wiki on transitioning profiles from the > apparmor-profiles package to the individual packages; > https://help.ubuntu.com/community/AppArmor#Migrating_an_apparmor-profiles_profile_to_a_package Thanks. I don't understand exactly what specific profiles we would want to migrate from apparmor-profiles to individual packages. Can you please elaborate? >> aforementioned software is supported, so I've extracted the profiles >> from the following Ubuntu packages, and have been running them in >> enforcing mode on my main Debian (sid) system: >> >> * firefox 11.0~b2+build1-0ubuntu1 > The firefox profile remains tricky as far as enabling by default. I agree it should probably not be enabled by default in Debian: the iceweasel beast is so huge, and extensions scope so large, that a "working-for-everyone" profile would probably be liberal to a point it would not be very different from unconfined. However, in the context of a Live system such as Tails, where we control quite well the deployed iceweasel setup, I believe an AppArmor profile makes sense. I guess many other kinds of managed deployements share this property, and in such deployements, supporting tons of random add-ons is probably not wished by the system administrators, if allowed at all by site policies. I would love to see such a minimal profile shipped, although disabled or in complain mode by default, in Debian. Do you think it makes sense / is doable? >> * evince 3.3.5-0ubuntu1 > This is pretty well tested by now. :) >> * isc-dhcp 4.1.1-P1-17ubuntu12 (client only) > Yes, very handy. Order of operations is important here, though. The profile > must load before any network interface. In Ubuntu, this is being done via > upstart jobs -- I haven't tested it with sysvinit. Ah, so this was the meaning of /etc/apparmor/init/network-interface-security/sbin.dhclient being a symlink to /etc/apparmor.d/sbin.dhclient in the Ubuntu patch. Makes sense. With sysvinit, I think that "Required-Start: $remote_fs" in the apparmor initscript will prevent AppArmor profiles to be loaded before the networking initscript starts. At least on my system, insserv ordered the scripts this way. Is this dependency present only to support the /usr-on-NFS usecase? The desktop + NetworkManager usecase works fine, though, but this is mostly by chance, and the network-manager initscript should probably be added a dependency on AppArmor. > One of the major stumbling blocks right now is that the "legacy > interface" patch is not carried by the Debian kernel. This means > that network mediation does not work at all, and that profile states > cannot be queried, which makes using AppArmor in production on > Debian rather troublesome. Agreed. > I've been working on building the new interface for the kernel, but > it is slow-going. Are you really working alone to upstream this? Is there some public place where this effort can be tracked and things to do documented? > In the meantime, it would be great if someone > could convince the Debian kernel maintainers to carry the interface > patch. My efforts there have failed in the past, but maybe new > people will succeed. What is the corresponding wishlist bug against the kernel? (Rationale: I'd like to report that aa-status and aa-genprof are unusable as is, so that the next adventurous people who happen to try AppArmor in Debian can easily find out what's happening, and these bugs should be marked as blocked by the one that tracks the lack of the "legacy interface" support in the kernel.) I think having a critical mass of people interested in AppArmor integration in Debian would probably help convincing the kernel team of carrying this patch. Chicken'n'egg, maybe. I'm more in the mood to get a handful of working profiles included, a motivated testing team assembled, and then we'll see what the kernel team thinks of it. > I've added [email protected] (the main AppArmor mailing > list) to the CC since a lot of distro integration discussion happens > there in addition to development work. Thank! > Frankly, I don't think AppArmor is in shape for "production" use in > Wheezy due to the kernel limitations. I don't think this is a big > problem -- it is available for people to start working with, and we > should continue to knock out any bugs we find, but I want to make > sure we set expectations correctly. Sure. I hope more people might get interested to work on it once it's at least useful and well integrated for a few, basic usecases and common applications. Let's get these usecases supported, then :) Thank you, Kees, for your feedback. This is much appreciated. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
