Come garantire la separazione dell'utente su un server shell della vecchia scuola


9

Voglio eseguire un server shell della vecchia scuola per un paio di persone, ad es. uno in cui gli utenti ottengono l'accesso ssh in modo da poter eseguire il software (proprio o fornito). La mia preoccupazione è la separazione appropriata tra gli utenti.

Non voglio che si vedano reciprocamente i processi, accedano ai file degli altri (a meno che non sia esplicitamente permesso), ecc. Sarebbe bello non essere morso da ogni bug di escalation di privilegi o riavviare il server con ogni aggiornamento minore del kernel. Sarebbe perfetto mantenere l'opzione di eseguire servizi comuni (come web e mail hosting) con queste misure di sicurezza in atto.

In passato ho usato grsec ma questo richiede di rimanere su un kernel più vecchio e di gestire la seccatura di compilarlo da soli. Esiste un modo più moderno e più Ubuntu per garantire la separazione dell'utente su un server condiviso?

Forse puoi fare qualcosa con AppArmor in tal senso? O forse esiste un repository di kernel preconfigurato per ambienti condivisi? O una soluzione basata su contenitori? Questi sono stati in voga di recente.


Risposte:


9

hidepid

procfssu Linux ora supporta l' hidepidopzione. Da 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.

Quindi, il montaggio /proccon hidepid=2è sufficiente per nascondere i dettagli dei processi di altri utenti su Linux> 3.3. Ubuntu 12.04 viene fornito con 3.2 per impostazione predefinita, ma è possibile installare kernel più recenti. Ubuntu 14.04 e versioni successive corrispondono facilmente a questo requisito.

ACL

Come primo passo, rimuovere le rwxautorizzazioni per gli altri da ogni home directory (e anche per il gruppo, se necessario). Suppongo, ovviamente, che le cartelle che contengono le home directory non abbiano i permessi di scrittura per nessuno tranne che per root.

Quindi, concedere a servizi come il server Web e il server di posta elettronica l'accesso alle directory appropriate tramite ACL. Ad esempio, per concedere al processo del server Web l'accesso alle home page dell'utente, supponendo che www-datasia l'utente ed ~/public_htmlè dove si trova la home page:

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

Allo stesso modo, aggiungere ACL per i processi di posta e le directory delle cassette postali.

Gli ACL sono abilitati di default su ext4 almeno su Ubuntu 14.04 e versioni successive.

/tmp e umask

Un altro problema è /tmp. Impostare in umaskmodo che i file non siano leggibili in gruppo o in tutto il mondo, in modo che i file temporanei degli utenti non siano accessibili ad altri utenti.


Con queste tre impostazioni, gli utenti non dovrebbero poter accedere ai file di altri utenti o esaminare i loro processi.


2
Un'alternativa o aggiunta a file separati inseriti /tmpè il pacchetto libpam-tmpdir: crea una directory /tmp/userdi proprietà root, non leggibile dal mondo e directory di proprietà dell'utente, non leggibili dal mondo, non attraversabili dal mondo /tmp/user/$UIDper ogni utente (al primo login) e imposta la variabile d'ambiente TMP_DIRin modo che punti a quest'ultima. La maggior parte dei programmi funziona bene e inserisce i propri file temporanei all'interno $TMP_DIRse impostati.
David Foerster,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.