Я хочу запустить старый добрый 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
так, чтобы файлы не были доступны для чтения группой или всем, чтобы временные файлы пользователей не были доступны другим пользователям.
При использовании этих трех настроек пользователи не смогут получать доступ к файлам других пользователей или просматривать их процессы.