Re: NIS/NFS Ersatz

From: Peter Ross <petros(at)pps.de>
Date: Fri, 5 Jan 2001 16:46:00 +0100 (MET)

Hi,

zum Thema Vertrauen:

1. Soetwas wie kerberos hilft schon eine ganze Ecke weiter.

2. Man muss ja keine Einladungen zum Datenklau aussprechen, da helfen u.a.:

   a) kein -maproot=0
   b) wenn Software geshart wird, kann man so konfigurieren, dass Read-Only-
      NFS-Mounts reichen
      (z.B. /usr/local, bei dem var ein Link auf die lokale Platte ist, wenn
      dort Prozessdaten landen, oder auf einen rw-gemounteten var-Bereich)
   c) exports mit ordentlich gefuehrter Liste von Hosts, die auf die Daten
      zugreifen duerfen
   d) nur exportieren, was anderswo wirklich gebraucht wird
   e) wenn WinDOSen via samba drauf zugreifen, ebenfalls gut gepflegte
      "hosts allow" in smb.conf
   f) Das Gleiche gilt fuer Mac-Zugriffe via netatalk
   g) bei den zugreifenden Servern darauf achten, dass sie nicht beliebig
      symbolischen Links folgen koennen (beliebt ist ein Link auf / unterhalb
      des Homeverzeichnisses, um "bequem" von Windows das System via samba
      "administrieren" zu koennen
   h) Dinge, die wirklich niemand aendern soll, mittels Secure Flags
      (chflags(1)) festklopfen, securitylevel nutzen.
   i) evt. auch lokal Read-Only-Mounts, wenn im Alltag niemand schreibend
      drauf zugreifen soll)
      
   h) und i) koennen durch Skripte fuer Installationen aufgehoben werden,
      (Single-User-Boot - admin.login - Installation - admin.logout - booten)
      wobei in admin.login rw-Mounts sowie chflags-Operationen stehen,
      in admin.logout die sicherheitserhoehenden Gegenstuecke,
      so dass Aenderungen einfacher sind - wenn der Admin samstags aendert
      und niemand sonst dann arbeitet).

Technische Moeglichkeiten ersetzen letztendlich nicht ein
sicherheitsorientiertes Firmenmanagement und strukturiertes Arbeiten;-)

Vor einiger Zeit konnte bei uns jeder Mac-Layouter rein theoretisch einen Haufen
Produktionsskripte wegwerfen, weil alle mit der gleichen Nutzerkennung
arbeiteten - das ist wohl nicht so nett.

Die Liste ist sicher nicht vollstaendig, das fiel mir nur alles eben gerade so
ein.

Es gruesst
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 05 Jan 2001 - 16:49:04 CET

search this site