Chcę uruchomić oldschoolowy serwer powłoki dla kilku osób, tj. taki, w którym użytkownicy uzyskują dostęp ssh, aby mogli uruchamiać oprogramowanie (własne lub dostarczone). Moim problemem jest odpowiednia separacja między użytkownikami.

Nie chcę, aby przeglądali się nawzajem, nie uzyskiwali dostępu do plików (chyba że jest to wyraźnie dozwolone) itp. Byłoby miło nie dać się ugryźć przez każdy błąd eskalacji uprawnień lub zrestartować serwer przy każdej drobnej aktualizacji jądra. Idealne byłoby utrzymanie opcji uruchamiania wspólnych usług (takich jak hosting stron internetowych i poczty) przy zachowaniu tych środków bezpieczeństwa.

Wcześniej użyłem grsec, ale wymaga to pozostania na starszym jądrze i radzenia sobie z kłopotami z samodzielnym skompilowaniem go. Czy istnieje bardziej nowoczesny i bardziej Ubuntu sposób zapewnienia separacji użytkowników na wspólnym serwerze?

Być może możesz zrobić coś z AppArmor w tym celu? A może istnieje repozytorium jąder wstępnie skonfigurowanych dla środowisk współdzielonych? Lub rozwiązanie oparte na pojemnikach? Były to ostatnio modne.

hidepid

procfsw systemie Linux obsługuje teraz tę hidepidopcję. Od man 5 proc:

hidepid=n (since Linux 3.3)
      This   option   controls  who  can  access  the  information  in
      /proc/[pid]  directories.   The  argument,  n,  is  one  of  the
      following values:

      0   Everybody  may  access all /proc/[pid] directories.  This is
          the traditional behavior, and  the  default  if  this  mount
          option is not specified.

      1   Users  may  not  access  files and subdirectories inside any
          /proc/[pid]  directories  but  their  own  (the  /proc/[pid]
          directories  themselves  remain  visible).   Sensitive files
          such as /proc/[pid]/cmdline and /proc/[pid]/status  are  now
          protected  against other users.  This makes it impossible to
          learn whether any user is running  a  specific  program  (so
          long  as  the program doesn't otherwise reveal itself by its
          behavior).

      2   As for mode 1, but in addition the  /proc/[pid]  directories
          belonging  to other users become invisible.  This means that
          /proc/[pid] entries can no longer be used  to  discover  the
          PIDs  on  the  system.   This  doesn't  hide the fact that a
          process with a specific PID value exists (it can be  learned
          by  other  means,  for  example,  by "kill -0 $PID"), but it
          hides a process's UID and  GID,  which  could  otherwise  be
          learned  by  employing  stat(2)  on a /proc/[pid] directory.
          This greatly complicates an  attacker's  task  of  gathering
          information   about  running  processes  (e.g.,  discovering
          whether some daemon is  running  with  elevated  privileges,
          whether  another  user  is  running  some sensitive program,
          whether other users are running any program at all,  and  so
          on).

gid=gid (since Linux 3.3)
      Specifies  the  ID  of  a  group whose members are authorized to
      learn  process  information  otherwise  prohibited  by   hidepid
      (ie/e/,  users  in this group behave as though /proc was mounted
      with hidepid=0.  This group should be used instead of approaches
      such as putting nonroot users into the sudoers(5) file.

Tak więc montowanie za /procpomocą hidepid=2wystarczy, aby ukryć szczegóły procesów innych użytkowników w systemie Linux> 3.3. Ubuntu 12.04 jest domyślnie dostarczany z wersją 3.2, ale możesz zainstalować nowsze jądra. Ubuntu 14.04 i nowsze wersje z łatwością spełniają to wymaganie.

ACL

Pierwszym krokiem jest usunięcie rwxuprawnień dla innych z każdego katalogu domowego (a także dla grupy, jeśli jest to wymagane). Zakładam oczywiście, że foldery zawierające katalogi domowe nie mają uprawnień do zapisu dla nikogo poza rootem.

Następnie udzielić usług, takich jak serwer WWW i serwer poczty, dostępu do odpowiednich katalogów za pomocą list ACL. Na przykład, aby przyznać procesowi serwerowemu dostęp do stron głównych www-dataużytkownika , zakładając, że użytkownik ~/public_htmljest miejscem przechowywania strony głównej:

setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html

Podobnie dodaj listy ACL dla procesów poczty i katalogów skrzynek pocztowych.

Listy ACL są domyślnie włączone na ext4 przynajmniej na Ubuntu 14.04 i nowszych.

/tmp i umask

Kolejny problem to /tmp. Ustaw umasktak, aby pliki nie były czytelne dla grupy lub świata, aby pliki tymczasowe użytkowników nie były dostępne dla innych użytkowników.

Dzięki tym trzem ustawieniom użytkownicy nie powinni mieć dostępu do plików innych użytkowników ani sprawdzać swoich procesów.