Re: sftp und virtual users

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Sun, 20 Mar 2011 03:36:24 +0100
On Sat, Mar 19, 2011 at 10:02:30PM +0100, Håkan Källberg wrote:
> On Sat, Mar 19, 2011 at 08:36:45PM +0100, Raphael Eiselstein wrote:
> > Håkan Källberg wrote:
> > > Die Unix User müssen 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 tatsächlich ein chroot-environment, in dem der sshd läuft.
> 
> 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/* unabhängig verwaltet werden können.[1]

openssh kann man aber scheinbar nicht nativ dazu bringen, User
ausschließlich(!) unabhängig von von /etc/passwd zu authentiizieren.

Aus genau diesem Grund benötige 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 Überlegung: Wenn ich für eine systemunabhängige sftp-Authentifi-
kation ein chroot bauen muss, dann kann ich auch für die einfache ftp-
Authentifikation einen ganz normalen vsftpd mit "real users" verwenden, 
der innerhalb des gleichen chroot läuft. Aktuell läuft schon ein vsftpd 
mit "virtual users", der Benutzer mit PAM über /opt/path/to/passwordfile 
authentifiziert.

> Viele Grüße:				Håkan

Gruß
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 können. Schon aus diesem Grund 
darf der von extern erreichbare ssh-Daemon keine Benutzer authtentifi-
zieren *können*, es muss also durch Konfiguration 100% ausgeschlossen 
werden. Schon allein für diese Sicherheitsanforderung ist ein chroot für
den *externen* ssh-Daemon fast unumgänglich. 

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 für das ganze System tun, zum Beispiel device-nodes für 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@uugrn.org>               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/

Empfangen am 20.03.2011

Dieses Archiv wurde generiert von hypermail 2.2.0 : 20.03.2011 CET