[Apparmor-general] AppArmor2 and Vsftpd question

[Christian Boltz]

Hello,

@Seth: your mail arrived with broken GPG signature here :-(

Am Montag, 26. Februar 2007 schrieb Vishwanath Callikan:
> I've been playing around AppArmor 2 for a while now and was recently
> asked if it was possible to effectively profile the vsftpd process if
> it is configured to accept chrooted ftp connections.
[...]

As Seth already wrote, protecting chrooted applications is problematic.

However, there's a workaround ;-)

My web hosting customers are chroot'ed into their homedir. What they see 
is:

cb at cboltz:/home/www/cboltz.de> ls -al
insgesamt 40
drwxr-xr-x  7 root   root   4096 19. Okt 13:43 .
drwxr-xr-x 53 root   root   4096 12. Feb 01:10 ..
drwxr-xr-x  3 root   root   4096 26. Feb 13:05 conf
drwxr-xr-x 14 cb     users  4096  4. Jan 11:37 httpdocs
drwx------  2 cboltz root   4096 18. Feb 2005  private
drwxr-xr-x  8 root   root   4096  2. Jun 2006  statistics
drwxrwx--T  2 cboltz web   16384 14. Feb 08:38 tmp

Now comes how the workaround works: uploads can be done to httpdocs, 
private and tmp only, downloads are also possible from the root-owned 
directories conf and statistics.

In other words: if someone really breaks the chroot, he can write 
to /httpdocs (which doesn't exist in the non-chrooted system - 
therefore no problem) and /tmp (not really critical, but could be 
avoided by renaming the directory to ~/tempfiles or alike).
He won't be able to access any system directory (except /tmp) simply 
because those directories like /httpdocs don't exist outside the 
chroot.


My vsftpd-profile looks like this (works on 10.1 and 10.2):

# cat usr.sbin.vsftpd

#include <tunables/global>

/usr/sbin/vsftpd {
  #include <abstractions/authentication>
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability setgid,
  capability setuid,
  capability sys_chroot,

  / r,           # in chroot
  /conf r,       # in chroot
  /conf/** r,    # in chroot
  /dev/urandom 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,
  /httpdocs r,      # in chroot
  /httpdocs/** rw,  # in chroot
  /private r,       # in chroot
  /private/** rw,   # in chroot
  /proc/meminfo r,
  /pub r,
  /pub/** r,
  /statistics r,     # in chroot
  /statistics/** r,  # in chroot
  /tmp rw,           # in chroot or system
  /tmp/** rw,        # in chroot or system
  /usr/sbin/vsftpd rmix,
  /var/log/vsftpd.log w,
  /var/log/xferlog w,
  @{HOMEDIRS} r,
  @{HOME}/** rwl,
}

Even if you don't want to restrict your customers to specific 
directories ("/** rw"), you can have a basic protection - execution of 
other applications is impossible with AppArmor.

Only exception: one could place a bad /usr/sbin/vsftpd (or as one of the 
paths in the used abstractions/* files) in the chroot and execute it 
(in mr/mixr mode), but it shouldn't have more permissions than the 
original vsftpd.


Regards,

Christian Boltz
-- 
Eine kurze richtige Antwort (mancher mag sie als unfreundlich
bezeichnen) ist besser als eine lange, freundliche, falsche.
[Dirk H. Hohndel, SuSE]