Я хочу запустить сервер оболочки старой школы для пары человек, т.е. тот, где пользователи получают доступ по SSH, чтобы они могли запускать программное обеспечение (свое или предоставленное). Меня беспокоит правильное разделение между пользователями.
Я не хочу, чтобы они просматривали процессы друг друга, обращались к файлам друг друга (если это явно не разрешено) и т. Д. Было бы неплохо не быть укушенным при каждой ошибке повышения привилегий или перезапускать сервер с каждым второстепенным обновление ядра. Было бы идеально поддерживать возможность запуска общих служб (таких как веб- и почтовый хостинг) с этими мерами безопасности.
Раньше я использовал grsec, но для этого нужно было остаться на старом ядре и заняться созданием его самостоятельно. Есть ли более современный и более Ubuntu способ обеспечить разделение пользователей на общем сервере?
Возможно, вы можете что-то сделать с AppArmor для этого? Или, может быть, есть хранилище ядер, предварительно настроенных для общих сред? Или решение на основе контейнеров? Они были в моде в последнее время.
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 и выше легко соответствует этому требованию.
Как первый шаг, удалить rwx
полномочия для других из каждого корневого каталога (и для группы также, если Вы требуете его). Я предполагаю, конечно, что папка (папки), содержащая корневые каталоги, не имеет полномочий записи никому кроме корня.
Затем сервисы предоставления как веб-сервер и доступ почтового сервера к соответствующим каталогам с помощью ACLs. Например, для предоставления веб-сервера обрабатывают доступ к пользовательским домашним страницам, принимая www-data
пользователь и ~/public_html
то, где домашняя страница сохранена:
setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html
Точно так же добавьте ACLs для почтовых процессов и каталогов почтового ящика.
ACLs включены по умолчанию на ext4, по крайней мере, на Ubuntu 14.04 и выше.
/tmp
и umask
Другая проблема /tmp
. Установите umask
так, чтобы файлы не были группой - или читаемый миром, так, чтобы временные файлы пользователей не были доступны для других пользователей.
С этими тремя настройками пользователи не должны мочь получить доступ к файлам других пользователей или исследовать их процессы.