☰

hidepid

tag-icon • tag-icon server kernel ssh security multi-user
hidepid

Я хочу запустить старый добрый shell-сервер для нескольких человек, т. е. такой, где пользователи получат доступ по SSH, чтобы они могли запускать программное обеспечение (свое собственное или предоставленное).Меня беспокоит вопрос надлежащего разделения пользователей.

Я не хочу, чтобы они просматривали процессы друг друга, получали доступ к файлам друг друга (если это явно не разрешено) и т. д. Было бы неплохо не кусаться из-за каждой ошибки повышения привилегий или не перезапускать сервер при каждом незначительном обновлении ядра. Было бы идеально сохранить возможность запуска общих служб (вроде веб-хостинга и почтового хостинга) с этими мерами безопасности.

Раньше я использовал grsec, но для этого пришлось бы использовать старое ядро ​​и иметь дело с хлопотами по его самостоятельной компиляции.Существует ли более современный и более соответствующий Ubuntu способ обеспечения разделения пользователей на общем сервере?

Может быть, можно что-то сделать с AppArmor в этом направлении? Или, может быть, есть репозиторий ядер, предварительно настроенных для общих сред? Или решение на основе контейнеров? Они в последнее время в моде.

решение1

hidepid

procfsна Linux теперь поддерживает эту hidepidопцию. От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.

Итак, монтирования /procс помощью hidepid=2достаточно, чтобы скрыть детали процессов других пользователей в Linux > 3.3. Ubuntu 12.04 поставляется с 3.2 по умолчанию, но вы можете установить более новые ядра. Ubuntu 14.04 и выше легко соответствуют этому требованию.

ACL-списки

В качестве первого шага удалите rwxразрешения для других из каждого домашнего каталога (и для группы, если вам это нужно). Я предполагаю, конечно, что папка(и), содержащая домашние каталоги, не имеет разрешений на запись ни для кого, кроме root.

Затем предоставьте службам, таким как веб-сервер и почтовый сервер, доступ к соответствующим каталогам с помощью ACL. Например, чтобы предоставить процессу веб-сервера доступ к домашним страницам пользователя, предположив, www-dataчто это пользователь и ~/public_htmlгде хранится домашняя страница:

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

Аналогичным образом добавьте списки контроля доступа для почтовых процессов и каталогов почтовых ящиков.

Списки управления доступом (ACL) включены по умолчанию в ext4, по крайней мере, в Ubuntu 14.04 и выше.

/tmpиumask

Другая проблема /tmp. Установите umaskтак, чтобы файлы не были доступны для чтения группой или всем, чтобы временные файлы пользователей не были доступны другим пользователям.

При использовании этих трех настроек пользователи не смогут получать доступ к файлам других пользователей или просматривать их процессы.

Связанный контент