Comment garantir la séparation des utilisateurs sur un serveur shell old school

9

Je veux exécuter un serveur shell old school pour quelques personnes, c.-à-d. celui où les utilisateurs obtiennent un accès ssh afin qu'ils puissent exécuter un logiciel (propre ou fourni). Ma préoccupation est une séparation appropriée entre les utilisateurs.

Je ne veux pas qu'ils se regardent mutuellement, accèdent aux fichiers les uns des autres (sauf autorisation explicite), etc. Il serait parfait de conserver la possibilité d'exécuter des services communs (comme l'hébergement Web et de messagerie) avec ces mesures de sécurité en place.

À l'époque, j'ai utilisé grsec mais cela nécessite de rester sur un noyau plus ancien et de gérer les tracas de le compiler vous-même. Existe-t-il un moyen plus moderne et plus Ubuntu d'assurer la séparation des utilisateurs sur un serveur partagé?

Peut-être pouvez-vous faire quelque chose avec AppArmor à cet effet? Ou peut-être existe-t-il un référentiel de noyaux préconfiguré pour les environnements partagés? Ou une solution basée sur des conteneurs? Celles-ci ont été en vogue récemment.

Putain de terminal
la source
Docker
Jakuje

Réponses:

9

hidepid

procfssous Linux prend désormais en charge l' hidepidoption. De 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.

Il suffit donc de monter /procavec hidepid=2pour masquer les détails des processus des autres utilisateurs sous Linux> 3.3. Ubuntu 12.04 est livré avec 3.2 par défaut, mais vous pouvez installer des noyaux plus récents. Ubuntu 14.04 et supérieur répondent facilement à cette exigence.

ACL

Dans un premier temps, supprimez les rwxautorisations pour les autres de chaque répertoire personnel (et pour le groupe également, si vous en avez besoin). Je suppose, bien sûr, que le (s) dossier (s) contenant les répertoires personnels ne dispose d'aucune autorisation d'écriture sur quiconque, à l'exception de root.

Ensuite, accordez à des services comme le serveur Web et le serveur de messagerie l'accès aux répertoires appropriés à l'aide des ACL. Par exemple, pour accorder au processus du serveur Web l'accès aux pages d'accueil de l'utilisateur, en supposant qu'il www-datas'agit de l'utilisateur et de l' ~/public_htmlendroit où la page d'accueil est conservée:

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

De même, ajoutez des ACL pour les processus de messagerie et les répertoires de boîtes aux lettres.

Les ACL sont activées par défaut sur ext4 au moins sur Ubuntu 14.04 et supérieur.

/tmp et umask

Un autre problème est /tmp. Définissez le umaskafin que les fichiers ne soient pas lisibles en groupe ou dans le monde, afin que les fichiers temporaires des utilisateurs ne soient pas accessibles aux autres utilisateurs.


Avec ces trois paramètres, les utilisateurs ne devraient pas pouvoir accéder aux fichiers des autres utilisateurs ni examiner leurs processus.

muru
la source
2
Une alternative ou un ajout à des fichiers séparés placés dans /tmpest le package libpam-tmpdir: il crée un répertoire appartenant à la racine, non lisible par le monde et des répertoires /tmp/userappartenant à l'utilisateur, non lisibles par le monde, non traversables par le monde /tmp/user/$UIDpour chaque utilisateur (dès leur premier connexion) et définit la variable d'environnement TMP_DIRpour pointer vers cette dernière. La plupart des programmes jouent bien et placent leurs fichiers temporaires à l'intérieur $TMP_DIRs'ils sont définis.
David Foerster