Hi,
On Thu, Feb 16, 2012 at 12:19:49AM +0100, intrigeri wrote:
> 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.
\o/ Glad it's been treating you well! :)
> >> 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.
Right, absolutely. I didn't mean to imply that we should just throw
everything possible at the maintainers. :)
> >> 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?
I didn't have any in mind, but I just wanted to point out the procedure
we've documented for doing it in the past. For example, if we wanted to
move the ping, traceroute, etc stuff to their packages, we'd follow that
process.
> >> 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?
Yeah, absolutely. This is effectively what's done in Ubuntu. Local
configuration or a derivative can enable it, etc.
> >> * 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.
Yeah, it's a bit weird, but that's the least of a few evils.
> 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?
I suspect so, yes. It probably means that apparmor will either need to have
2 init files (early and late), or have its init modified not to require
/usr. Both we done at various times before in Ubuntu, so it shouldn't be
much work to make it happen.
> 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.
Yeah; I've been just trying to stabilize the packaging and Ubuntu
coordination so far. Getting things into a more admin-friendly state is
coming. :)
> > 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?
Presently the bulk of the kernel work is being done by John Johansen. I
help out around the edges. In this case, I took on trying to implement the
interface design that was discussed here:
https://lists.ubuntu.com/archives/apparmor/2010-November/000491.html
https://lists.ubuntu.com/archives/apparmor/2011-December/001912.html
> > 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?
I don't think there is one at the moment.
> (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.
Yup, I'd be happy to have those bug open, but since I've got enough things
that already need fixing, I haven't opened them yet myself. :)
> > 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.
Sure thing! Thanks for your interest and work! :)
-Kees
--
Kees Cook @debian.org
