[apparmor] AppArmor 2.8 beta2

[Christian Boltz]

Hello,

Am Montag, 12. März 2012 schrieb John Johansen:
> On 03/12/2012 03:42 PM, Christian Boltz wrote:
> > Am Samstag, 10. März 2012 schrieb John Johansen:
> >> * profiles have been defaulted to chroot relative instead of
> >> namespace relative
> > 
> > What does that mean in practise?
> > 
> > To give a real-world example: I have a profile for vsftpd [1] that
> > allows
> > 
> >     /home/www/*/httpdocs/** rw,
> > 
> > Users are chrooted to their home directory (/home/www/*/) when they
> > login with FTP.
> > 
> > Do I have to change my profile to
> > 
> >     /httpdocs/** rw,
> > 
> > (which would be bad IMHO)?
> 
> yes.  As to bad yes and no it depends on how you are developing your
> policy.  From a visibility view point it makes a lot of sense, from
> a I want to think about this from a system filesystem pov not so
> much.

My usual viewpoint is the filesystem POV. Hey, it's just a program or 
FTP user that is chrooted, not me ;-)

Additionally, there might be overlaps inside and outside the chroot - 
and I'd like to avoid that a program gets too much permissions in the 
"real" filesystem. Just think of
    /** rw,
which is quite common for a chrooted FTP user in chroot_relative 
notation. You don't want to (accidently) apply this rule for the real 
filesystem ;-)

> Think of it like this, You are virtualizing a sub OS in a chroot
> what should its profiles look like?
> 
> Well host system profiles would want to see the full path
> (namespace_relative) and profiles loaded inside the chroot would want
> to be chroot_relative.

Most probably yes if we are talking about a sub OS (because that makes 
it easier to use abstractions etc.), but for just chrooting FTP users I 
prefer using the full path.

Anyway, we seem to agree that the main profile should always use the 
full path.

> I think the other thing you are missing is chroot rules, which where
> supposed to land in 2.8 but didn't.  

Yes, I've seen the discussion, but somehow failed to ask earlier ;-) 
ENOTIME, ETOOMUCHONTODOLIST or something alike. 
Sorry for asking that late.

> This would mean instead of
> staying in the say profile at chroot point, you could transition into
> another say a child profile, which would only list what was available
> from within the chroot.

OK, if we have something like

    chroot /home/www/*/ -> ^subprofile

then it can make sense to make this subprofile chroot_relative. 
However I don't see why we can't just explicitely specify the 
chroot_relative flag on the ^subprofile to make it clear. The parser 
could even warn if a chroot target profile is not flagged as 
chroot_relative or namespace_relative.

Another idea would be (to enable using existing profiles or subprofiles 
without the need to add a chroot_relative flag on them):

    chroot /home/www/*/ -> ^subprofile (chroot_relative)


Everything else should stay namespace_relative because of
- backward compability (never change the meaning of a profile!)
- principle of least surprise (just think you know nothing about 
  AppArmor and your first contact is by reading a profile) - which 
  behaviour would you expect in the main profile?

If we really want to do such a change, we should finally implement 
versioning in the profiles - there were lots of discussions about this, 
but until now nobody implemented it ;-)


BTW: I remember that a very old version of AppArmor (2.3?) was indeed 
chroot_relative. I always thought of that as a bug (which might even 
introduce security issues if chroot and the real filesystem overlap) and 
was very happy when it was fixed^Wchanged.

Needless to say that I like your proposal to revert to 
namespace_relative by default ;-)


Regards,

Christian Boltz
-- 
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch.        [Anselm Lingnau]