frangipane/ WebSiteEditingArchive

Web sites editing (discussion archive page)

  1. SSH restricted shells
    1. scponly
    2. rssh
    3. chrootssh
    4. libpam-chroot
    5. VServer
    6. Maintaining chroot jails
  2. WebDAV
  3. Network file systems
  4. FTPs
    1. vsftpd
    2. ProFTPd

The web sites admins need to edit their sites files with a FTP-like method, without any password or bit of data travelling in cleartext over the Internet.

After studying the following solutions, we finally decided to use another solution, which is described on WebSite.

SSH restricted shells

All these "restricted shells" try to emulate FTP over SSH, by analysing the commands sent by SSH, and deciding if they are legal or not ; this is not really strong, and they all have had quite a lot security holes in the past (i.e. various ways have been found to run arbitrary commands on the server).

We thus don't want to trust such solutions, so they have to run inside the web hosting VServer ; as we don't want to make a site's DocumentRoot his home directory (in case we want to put access logs or whatever inside this home directory), this implies to :

  • bind mount every /var/www/DOMAIN.TLD/SITE into /home/www/DOMAIN.TLD/SITE/www ; this can maybe be done in a clean way using pam-mount, so that such bind mounts are made only when needed
  • setup libnss-pgsql in this VServer so that web sites users are known
  • maintain one minimal chroot jail per website

Riseup lists sftp clients for the various OS on http://help.riseup.net/hosting/sftp/.

scponly

rssh

chrootssh

  • http://chrootssh.sourceforge.net/index.php
  • allows to use sftp-server (bundled with SSH) as a shell for restricted users
  • requires to have a minimal chroot for every restricted user. Maybe a statically built sftp-server binary is enough.
  • One of us worked heavily on a chrootssh + statically compiled sftp-server : WebSiteChrootedStaticSftp ; this is a pain to maintain and update : NO

libpam-chroot

VServer

The VServer unification is supposed to allow us to easily maintain several VServers running the same system ; we could setup one VServer per website, running only sshd ; but... on which IP/port would all these sshd's listen ? NO

Maintaining chroot jails

  • apt-cache show makejail : maintains only one jail per config file ; more oriented to trace daemons and find which files they need, but might suit our need though
  • jailer and jailtool : Debian packaged ; able to deal with a Debian packages list, or with files ; really debian-packages oriented, which makes it really hard to maintain a minimalist chroot ; another program could be used to give us the list of needed files, and jailer or jailtool would happily maintain the chroot.
  • scpjailer
  • Securing Debian
  • need a filesystem mounted with nosuid and/or noexec options ?
  • a statically compiled sftp-server binary is much more secure than putting a whole libc into the chroot jails

WebDAV

Although WebDAV is appealing, since it is supported by tons of clients (Konqueror, Windows Web Folders, Emacs interface...), there is no WebDAV server supporting our "one UID per site" setup, i.e. a server that would act as vsftpd, running as root, able to lookup the UID/GID to use for a given directory either in a database/NSS or with a setuid-like mechanisme as suPHP does, and spawning one child process running under this UID for every connexion.

Network file systems

Is there a single one with encryption support, and well supported on various platforms ? There are a few, but they all require heavy client configuration, and most of the time root access to the client box, or even custom kernel compile ; NFS4 and AFS were already discarded based on these reasons. What's left ? No, don't tell us Samba.

FTPs

%X% FTP over SSL can not be tracked by netfilter's ip_conntrack_ftp, which is maybe a blocking issue...

A ugly hack would be to :

  • run vsftpd on a dedicated IP
  • make sure that only vsftpd is listening on this IP
  • in the firewall INPUT chain, ACCEPT all connections to this IP on a >32000 port range

A less ugly hack : reserve a port range for vsftpd with iptables/netfilter

  • if we choose a "one UID per website model", this implies to dynamically configure iptables/netfilter based on frangipane's DB via netfilter INPUT UID matching. Risky, hum ? This seems impossible since netfilter UID matching is only valid in the OUTPUT chain.

vsftpd

  • sait s'authentifier sur PAM, libnss-pgsql
  • rock secure
  • sait faire du ftp crypté (SSL, TLS), cf http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext_col.html
  • if we choose a shared-UID model, vsftpd provides a virtual users + chroot'd-home system, thanks to the options user_sub_token, guest_username and local_chroot (see man vsftpd.conf for details)
  • seems to have problems with disk quotas (if quota is reached, files are uploaded with zero size ; maybe fixed in recent versions ?)
  • various issues with umask customization, but solutions and patches seem available

ProFTPd