Re: sftp und virtual users

[Raphael Eiselstein <rabe@xxxxxxxxx>]

On Sat, Mar 19, 2011 at 10:02:30PM +0100, HÃ¥kan Kaellberg wrote:
> On Sat, Mar 19, 2011 at 08:36:45PM +0100, Raphael Eiselstein wrote:
> > HÃ¥kan Kaellberg wrote:
> > > Die Unix User muessen mit einem * in /etc/shadow angelegt sein.
> 
> > Das ist schade, weil ich die Verwaltung der Systemaccounts und die der
> > Dienstbenutzer (sftp-Accounts) getrennt halten will (muss). Also brauche
> > ich hier wohl tatsaechlich ein chroot-environment, in dem der sshd laeuft.
> 
> Das verstehe ich nicht ganz... Chroot macht doch sshd selber:
> 
> > >         ChrootDirectory %h

Aus sshd_config(5):

ChrootDirectory
  Specifies the pathname of a directory to chroot(2) to *after* authentication.

Das bedeutet, dass ich alle sftp-Benutzer in meiner /etc/(passwd|shadow)
anlegen muss, in der ich auch meine normalen Systemaccounts habe, also
Adminaccounts etc. Diese Dateien werden vollautomatisch und 
zentralisiert gepflegt, ich kann (will) also in /etc/* keine "Kunden-
Accounts" pflegen. 

Daher war auch meine "Anforderung", dass es "Virtual Users" sein sollen, 
also Benutzer, die von /etc/* unabhaengig verwaltet werden koennen.[1]

openssh kann man aber scheinbar nicht nativ dazu bringen, User
ausschliesslich(!) unabhaengig von von /etc/passwd zu authentiizieren.

Aus genau diesem Grund benoetige ich also doch ein chroot-System, z.B. 
unter /opt/server/sftp/, allein damit ich unterscheiden kann zwischen 
/etc/passwd und /opt/server/sftp/etc/passwd und zwischen /usr/sbin/sshd 
und /opt/server/sftp/usr/sbin/sshd. 

Weitere Ueberlegung: Wenn ich fuer eine systemunabhaengige sftp-Authentifi-
kation ein chroot bauen muss, dann kann ich auch fuer die einfache ftp-
Authentifikation einen ganz normalen vsftpd mit "real users" verwenden, 
der innerhalb des gleichen chroot laeuft. Aktuell laeuft schon ein vsftpd 
mit "virtual users", der Benutzer mit PAM ueber /opt/path/to/passwordfile 
authentifiziert.

> Viele Gruesse:				HÃ¥kan

Gruss
Raphael

PS: 1. Der entscheidende zweite entscheidende Aspekt ist, dass Benutzer, 
die in /etc/shadow bzw /etc/passwd angelegt sind idR normale Admins
sind. Admins haben idR sehr hohe Rechte am System via sudo. 

Es *muss* ausgeschlossen sein, dass sich hochprivilegierte User direkt 
aus dem Internet auf dem System einloggen koennen. Schon aus diesem Grund 
darf der von extern erreichbare ssh-Daemon keine Benutzer authtentifi-
zieren *koennen*, es muss also durch Konfiguration 100% ausgeschlossen 
werden. Schon allein fuer diese Sicherheitsanforderung ist ein chroot fuer
den *externen* ssh-Daemon fast unumgaenglich. 

PPS: Ich vermisse Jails unter Linux. Ein chroot-Environment ist zwar
schon ganz gut, aber wenn es kompromittiert wird und root-Rechte
eskaliert werden, kann man auch aus einem chroot heraus sehr unangenehme
Dinge fuer das ganze System tun, zum Beispiel device-nodes fuer die
Systemplatten in /dev anlegen und die Systemplatte einfach ins chroot
mounten, oder aber auf Prozesse zugreifen, die ausserhalb des chroots
laufen (z.B. kill 1). 

PPPS: Ich weiss, dass Linux-Container ("Linux-Jails") existieren. Ich 
hab damit bisher keine Erfahrungen gemacht.

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/