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 apparmor@??? (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?
