[apparmor] AppArmor 2.8 beta2

[Christian Boltz]

Hello,

Am Mittwoch, 14. März 2012 schrieb John Johansen:
> On 03/13/2012 01:39 PM, Christian Boltz wrote:
> > 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

> > My usual viewpoint is the filesystem POV. Hey, it's just a program
> > or FTP user that is chrooted, not me ;-)
> 
> Well yes, I can understand to pov.  I don't want to take away the
> ability to express profiles in the form.  Just mark them up in such a
> way that the tools can correctly interpret what needs to be done, and
> can continue to be done with changes in the underlying
> implementation.
> 
> There is a mess of confusion around file system namespace, chroots and
> profiles that needs to be made consistent.

I wouldn't call the current profiles a mess or inconsistent ;-)

Maybe if you look at the profile from the chroot'ed POV, then you might 
get slightly confused. But "I'm root, I'm never chroot'ed" ;-)

> > 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 ;-)
> 
> I would NEVER propose overlaping pre and post chroot paths, that is
> just broken. And indeed its one of the failure points that is
> encountered with fs namespaces atm, 

Well, at the moment I don't see a real problem because all profiles are 
always filesystem relative. 

Oh, there's another possible problem - sharing profiles between two 
apparmor versions. If chroot_relative becomes the default, then you will 
get a "/** rw" rule for FTP uploads (chroot relative), but older 
versions will interpret it as filesystem relative.

> and will be until full implicit labeling comes on line.

What about enforcing _explicit_ labeling in the profile everything that 
is meant chroot relative?

> Because fs namespaces don't have root requirements that are the same
> as chroots, there is no way to get back to the pre namespace change
> path, and the attach_disconnected flag must be used, which effectively
> causes the overlap you just pointed out above.

attach_disconnected is another technical detail I don't really 
understand yet. Do you have an explanation at hand that the average 
winegrower (like me) can understand? ;-)

> > Anyway, we seem to agree that the main profile should always use the
> > full path.
> 
> It would be easier, but there is going to need to be some magic,
> especially around fs namespaces, which are being used interchangeably
> in some places.

What type of "magic"?

> > 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.
> 
> Hehe but you be able to.
> 
> > 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)
> 
> I am open to ideas, since we are reverting all of it from 2.8 there is
> more time to kick around the design and requirements

OK, then just save my ideas from above somewhere ;-)

> > Everything else should stay namespace_relative because of
> > - backward compability (never change the meaning of a profile!)
> 
> I understand this pov, but this may not even be possible in the future
> or at least not in the current form.  This is one of the reasons to
> begin pushing for the change.  The other being consistency between
> chroot and fs namespaces.
> 
> If we break things I promise it will be a fail closed situation.

Can you rephrase that to
    If we break things I promise we will implement profile versioning 
    first.
please? ;-)

> We need to mark up one or the other case, and the chroot case for
> profiles is much less common, so its the one we should be targeting.

Yes, chroot is indeed less common. Nevertheless, if the change can be 
done in a non-breaking way, I'd really prefer that.

> There are things we can do to auto detect, like chroot rules with no
> transition means the profile is being mixed and should be using
> namespace relative.

Agreed, even if I'd propose another style of autodetection:
"If there is no chroot_relative flag, the profile is namespace relative"

> Even in namespace relative profiles I would like to see moving to a
> variable root, for chroot paths
> 
> Eg.
> 
>   chroot /home/www/*,
> 
>   @{root}/foo rw,
> 
> its not required but it would aid in analysis and make it easier to
> get a tighter dynamic profile.

Yes, looks like a good idea.

> > - 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?
> 
> well again define main profile?

With "main profile" I mean the part outside the chroot. In case of 
vsftpd, it would be something like:

/usr/sbin/vsftpd {

### main profile start ###
  #include <abstractions/authentication>
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability setgid,
  capability setuid,
  capability sys_chroot,

  /dev/urandom r,
  audit /etc/ r,
  /etc/environment r,
  /etc/fstab r,
  /etc/ftpusers r,
  /etc/hosts.allow r,
  /etc/hosts.deny r,
  /etc/mtab r,
  /etc/shells r,
  /etc/vsftpd.* r,
  /etc/vsftpd/* r,
  owner /proc/*/mounts r,
  /usr/sbin/vsftpd mrix,
  /var/log/vsftpd.log w,
  /var/log/xferlog w,
### main profile end ###

### chroot part start - FTP users are chrooted to /home/www/*/ ###
  /home/www/*/ rk,
  /home/www/*/backup/ rk,
  /home/www/*/backup/** rk,
  /home/www/*/conf/ rk,
  /home/www/*/conf/** rk,
  /home/www/*/httpdocs/ rk,
  /home/www/*/httpdocs/** rwk,
  /home/www/*/private/ rk,
  /home/www/*/private/** rwk,
  /home/www/*/statistics/ r,
  /home/www/*/statistics/** rk,
  /home/www/*/tmp/ rk,
  /home/www/*/tmp/** rk,
### chroot part end

}

(and yes, this is my profile for vsftpd - if someone wants to grab it, 
feel free to do so. Needless to say the /home/www/* paths are specific 
to my setup.)

> > 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 ;-)
> 
> Well, we can always bring that discussion up again

IMHO we _must_ use versioning if we change the meaning of existing 
profiles. (Or, even better, avoid changes that change the meaning of 
existing profiles ;-)

> > 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.
> 
> 2.0 I think, maybe 2.1 but I doubt it

IIRC it was one of the first versions in openSUSE that didn't have the 
restriction to some hardcoded programs to confine. (Not sure if that 
helps to answer the question.)

(Digging that up might become an interesting history lesson, similar to 
the question which update applet was used in which openSUSE version ;-)

Oh, BTW, there's https://bugzilla.novell.com/show_bug.cgi?id=740327 for 
a named profile that still contains traces from those days. (The bind 
changelog contains "added apparmor profile" from May 2007.)

> > Needless to say that I like your proposal to revert to
> > namespace_relative by default ;-)
> 
> well you get your wish :)

:-)


Regards,

Christian Boltz
-- 
> Entscheiden was du brauchst musst du vorher, ein absolut stabiles 
> System(das ist stable bei Debian unbestritten) oder etwas aktuelles
Das Ding ist so stabil, daß ein "clamscan" sogar zu 100% reproduzierbar
einfriert -- seit einem Dreivierteljahr.
[Uwe Driessen und Peer Heinlein in postfixbuch-users]