LINUX.ORG.RU

Ограничить пользователя в shell (терминал ssh) на просмотр конфигов и важных папок

 ,


0

2

Добрый день

*** CentOS 6.6 ***

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

В сети на подобные вопросы, где люди как-то хотят ограничить пользователей по ssh, очень часто можно увидеть подобные комментарии:

простите, но у вас активные галлюцинации.

иначе я это назвать не могу. Расскажите пожалуйта, что вы можете сделать на прямо настроеном сервере, обычным пользователем?

Не знаю к чему эти комментарии, но разве это нормально, когда обычный пользователь ssh, доступ к которому предоставлен клиенту, а клиент дал этот доступ одному, второму, третьему человеку, и каждый заходит, спокойно гуляет по системе, просматривает конфиги, тем самым знает: в passwd - в системе такие есть пользователи, group - в системе такие есть группы, видит в какой группе какие есть пользователи, видит все конфиги на все программы и т.д. - разве это нормально?

Вопрос, как можно ограничить обычного пользователя, чтобы он не мог по ssh (shell) видеть то, что ему видеть не надо, и нужно ли это вообще делать, т.к. почитав подобные комментарии думаю, может я чего-то не понимаю?

Спасибо.



Последнее исправление: Nezhnayka28 (всего исправлений: 3)

Ответ на: комментарий от erzent

создаёшь пользователя с правами чисто на нужные ему директории и всё.

Вопрос, как это сделать? Выписать необходимые папки и файлы и потом руками ходить и на каждую папку и файл из этого списка назначать правильные права? + очень много файлов и папок, на которые заведомо необходимо дать доступ пользователю, чтобы правильно функционировала система, о которых я даже могу не подозревать.

Плюс например доступ на тот же /etc/passwd нужен пользователю, чтобы он мог авторизоваться.

Nezhnayka28
() автор топика

ssh умеет делать chroot. Можно ограничить доступ пользователю определенным каталогом выше которого он не поднимется

JB ★★★★★
()
Последнее исправление: JB (всего исправлений: 2)
Ответ на: комментарий от JB

Да, видел такую статью здесь: http://forum.ispsystem.com/ru/showthread.php?t=3528&page=4

но прочитав ее понял, что это не намного проще, чем ходить руками назначать права на каждую папку или файл необходимый пользователю + там еще нужно openssh пересобирать. Правда статья не первой свежести, может что-то уже изменилось с тех пор?

Кстати комментарий:

простите, но у вас активные галлюцинации. иначе я это назвать не могу. Расскажите пожалуйта, что вы можете сделать на прямо настроеном сервере, обычным пользователем?

как раз оттуда

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

Плюс монтирование надо производить необходимых папок и файлов пользователя

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

Патчить и пересобирать openssh не нужно, оно давно умеет чрут изкоробки.

Помимо классических юникcовых прав можно воспользоваться acl (setfacl), он куда более тонко настраивается и меньше шансов изговнякать права для остальных юзеров. Но тут опять надо иметь четкий набор файлов, куда нужен доступ, и ходить по ФС запрещая-разрешая. Если уж даже /etc видеть не положено.

Так что лучше чрут.

entefeed ☆☆☆
()

видит все конфиги на все программы и т.д. - разве это нормально?

Критические конфиги обычно шифруются и/или имеют read только для рута. С той информацией которая world-readable твой пользователь ничего криминального не наделает. Ну, конечно если админ не облажался.

entefeed ☆☆☆
()

тем самым знает: в passwd - в системе такие есть пользователи, group - в системе такие есть группы, видит в какой группе какие есть пользователи, видит все конфиги на все программы и т.д. - разве это нормально?

Да это нормально. Если защита системы состоит в том, чтобы не показывать passwd, то вот это - не нормально.

no-such-file ★★★★★
()

но разве это нормально, когда обычный пользователь ssh, доступ к которому предоставлен клиенту, а клиент дал этот доступ одному, второму, третьему человеку

Вот ЭТО и есть ненормально - «дать доступ» «одному, второму, третьему человеку». Всё остальное лишь следствие.

no-dashi ★★★★★
()
Ответ на: комментарий от entefeed

Патчить и пересобирать openssh не нужно, оно давно умеет чрут изкоробки

Понял, а монтировать папки и файлы в домашнюю директорию пользователя нужно?

Если уж даже /etc видеть не положено.

Так я же и спрашиваю, нужно ли вообще ограничивать пользователя в просмотре /etc/ и все что там есть? ))) Просто не могу понять, неужели ничего страшного в этом нет, что пользователь, через которого по shell будет ходить неограниченное количество людей, может просматривать конфиги всех программ и конфиги самой системы, пользователей, группы, вхождение пользователей в группы и т.д?

Но тут опять надо иметь четкий набор файлов, куда нужен доступ, и ходить по ФС запрещая-разрешая.

Можете подсказать приблизительный набор системных папок и файлов на которые необходимо дать доступ обычному shell пользователю, без которых просто не будет работать система с ним?

Если честно, вообще не думал, что так сложно будет в таком вроде простом вопросе на первый взляд.

Nezhnayka28
() автор топика
Ответ на: комментарий от no-dashi

Вот ЭТО и есть ненормально - «дать доступ» «одному, второму, третьему человеку».

Так предположим я настроил веб-сервер на CentOS, дал пользователя shell клиенту, клиент работает с разными специалистами в области веб-разработки (веб-программисты и т.д.). Мне отвечать за работоспособность и безопасность системы. Мне как-то не очень спокойно, когда я знаю что придет неограниченное количество людей по shell, у которых доступ на просмотр всех системных конфигов + просмотр всех конфигов программ установленных в системе + пользователи, группы, права.

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

если речь о вебе, то пользователю вообще нечего делать дальше каталога с его сайтом

JB ★★★★★
()
Ответ на: комментарий от JB

спрошу, раз никто еще не спросил - зачем пользователю вообще ssh доступ к серверу?

Например веб-программист захочет через программу HeidiStart подключиться к MySql серверу, чтобы работать с ним, да и других много случаев может быть. Другое дело что может shell как то можно выключить у этого пользователя? + например когда человек покупает самый обычный виртуальный хостинг, ему предоставляется доступ по ssh. Да и если там подключится по shell, то там будет ограниченное количество доступных папок и файлов на просмотр, пользователь shell их даже не видит в системе.

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

Например веб-программист захочет через программу HeidiStart подключиться к MySql серверу, чтобы работать с ним

для этого не нужен ssh

логин в mysql и учетная запись в системе это две разные вещи

например когда человек покупает самый обычный виртуальный хостинг, ему предоставляется доступ по ssh. Да и если там подключится по shell, то там будет ограниченное количество доступных папок и файлов на просмотр, пользователь shell их даже не видит в системе.

это chroot ssh

JB ★★★★★
()
Ответ на: комментарий от Nezhnayka28

Если честно, вообще не думал, что так сложно будет в таком вроде простом вопросе на первый взляд.

Это простой вопрос с простым решением. В общем случае ничего защищать не надо, ничего страшного в этом нет, ничего важного юзер без привилегий не увидит и не наделает. Все же не винда. Если нужна изоляция по-хардкору, чтоб никто никого не видел и не знал, то надо каждому юзеру делать чрут, а еще лучше отдельный контейнер. И общаться (если нужно) между ними через NFS, например.

Можете подсказать приблизительный набор системных папок и файлов на которые необходимо дать доступ обычному shell пользователю, без которых просто не будет работать система с ним?

Черт знает. Зависит от того, что юзер делать будет. Я бы посмотрел файло, из которого состоит твоя голая свежеустановленная система, и выдал бы юзеру права только на эти файлы. На все остальное, что будет доставляться после - запрещать.

entefeed ☆☆☆
()
Ответ на: комментарий от entefeed

Это простой вопрос с простым решением. В общем случае ничего защищать не надо, ничего страшного в этом нет, ничего важного юзер без привилегий не увидит и не наделает. Все же не винда.

ИМХО, это из разряда «можно, но не нужно»

JB ★★★★★
()
Ответ на: комментарий от JB

для этого не нужен ssh

да вроде нужен, http://itmages.ru/image/view/2455136/c51c6870

это chroot ssh

понятно, спасибо.

Это простой вопрос с простым решением. В общем случае ничего защищать не надо, ничего страшного в этом нет, ничего важного юзер без привилегий не увидит и не наделает. Все же не винда.
Черт знает. Зависит от того, что юзер делать будет. Я бы посмотрел файло, из которого состоит твоя голая свежеустановленная система, и выдал бы юзеру права только на эти файлы. На все остальное, что будет доставляться после - запрещать.

спасибо, принял к сведению, но на самом деле задумался, а надо ли пользователя ограничивать... ммм... что-то в тупик зашел, может на самом деле не надо O_o

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

да вроде нужен, http://itmages.ru/image/view/2455136/c51c6870

это для организации ssh туннеля средствами putty

спасибо, принял к сведению, но на самом деле задумался, а надо ли пользователя ограничивать... ммм... что-то в тупик зашел, может на самом деле не надо O_o

сделай ему ssh chroot в пользовательский каталог. Что бы сделать туннель этого хватит с головой, а по системе лазить ему не нужно

JB ★★★★★
()
Последнее исправление: JB (всего исправлений: 3)
Ответ на: комментарий от JB

это для организации ssh туннеля средствами putty

Так для этого нужно указать ssh пользователя (в подсказке «Пользователь shell»). Под этим же пользователем человек может зайти через ssh терминал и увидеть те все папки и файлы, о которых говорим здесь.

повторю вопрос. Зачем пользователю ssh? Какие у него задачи?

Черт его знает, какие задачи могут возникнуть у веб-разработчиков, у клиента, я просто отталкиваюсь от обычного виртуального хостинга, где хостер выдает доступ к пользователю ssh с shell правами - значит такая необходимость есть.

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

Так для этого нужно указать ssh пользователя (в подсказке «Пользователь shell»). Под этим же пользователем человек может зайти через ssh терминал и увидеть те все папки и файлы, о которых говорим здесь.

я знаю как это работает :)

как я уже написал - чрута средствами ssh для этого будет достаточно

Черт его знает, какие задачи могут возникнуть у веб-разработчиков, у клиента, я просто отталкиваюсь от обычного виртуального хостинга, где хостер выдает доступ к пользователю ssh с shell правами - значит такая необходимость есть.

опять таки, ssh chroot

JB ★★★★★
()
Ответ на: комментарий от JB

сделай ему ssh chroot в пользовательский каталог. Что бы сделать туннель этого хватит с головой, а по системе лазить ему не нужно

А, не заметил этот коммент, спасибо.

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

В продолжение темы, сделал chroot в пользовательский каталог:

Match user newuser
       ChrootDirectory /home/newuser
       X11Forwarding no
       AllowTcpForwarding no
но система не пускает этого пользователя в shell и в ssh туннель средствами putty так-же не пускает - там скорее всего минимальное окружение нужно сделать, не подскажите как в CentOS это сделать?

Nezhnayka28
() автор топика
# getent passwd medsys
medsys:x:1002:2240:Medusa User:/home/medsys:/usr/bin/rssh

# grep -vE '^#|^$' /etc/rssh.conf 
logfacility = LOG_USER 
allowscp
allowsftp
umask = 022
user=medsys:022:00011:/data1/medusa_south  # both with chroot

В данном случае /data1/medusa_south это «/» юзера

# ls -F /data1/medusa_south

bin/ dev/ etc/ home/ lib64/ usr/


# tree bin etc dev home lib64 usr
bin
|-- bash
|-- cat
`-- sh -> bash
etc
|-- group
|-- hosts
|-- ld.so.cache
|-- ld.so.conf
|-- nsswitch.conf
|-- passwd
|-- resolv.conf
|-- rssh.conf
|-- shadow
`-- shells
dev
|-- null
`-- zero
home
`-- medsys
         [SKIP]
lib64
|-- ld-linux-x86-64.so.2
|-- libc.so.6
|-- libcom_err.so.2
|-- libcrypt.so.1
|-- libcrypto.so.6
|-- libdl.so.2
|-- libkeyutils.so.1
|-- libnsl.so.1
|-- libnss_compat.so.2
|-- libnss_files.so.2
|-- libpthread.so.0
|-- libresolv.so.2
|-- libselinux.so.1
|-- libsepol.so.1
|-- libtermcap.so.2
`-- libutil.so.1
usr
|-- bin
|   |-- ldd
|   |-- rssh
|   |-- scp
|   `-- sftp
|-- lib64
|   |-- libgssapi_krb5.so.2
|   |-- libk5crypto.so.3
|   |-- libkrb5.so.3
|   |-- libkrb5support.so.0
|   |-- libnspr4.so
|   |-- libnss3.so
|   |-- libnssutil3.so
|   |-- libplc4.so
|   |-- libplds4.so
|   `-- libz.so.1
`-- libexec
    |-- openssh
    |   `-- sftp-server
    `-- rssh_chroot_helper

Все просто, если не ныть.

anonymous
()
Ответ на: комментарий от Nezhnayka28

Можно просто скопировать. В гугле по запросу «ssh chroot» много готовых скриптов для этого

JB ★★★★★
()
Ответ на: комментарий от Nezhnayka28

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

да ладно тебе.

t184256 ★★★★★
()
Ответ на: комментарий от JB

Можно просто скопировать. В гугле по запросу «ssh chroot» много готовых скриптов для этого

/etc/selinux/config

SELINUX=disabled

Создал группу:

groupadd chrooted
Создал пользователя:
useradd usertest -G chrooted
passwd usertest

/etc/ssh/sshd_config Пробовал и такой вариант:

#Subsystem<---->sftp<-->/usr/libexec/openssh/sftp-server

AllowGroups sshusers chrooted
Match Group chrooted
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no
и такой вариант (хотя меня sftp мало интересует, только shell):
#Subsystem<---->sftp<-->/usr/libexec/openssh/sftp-server
Subsystem<----->sftp<-->internal-sftp
AllowGroups sshusers chrooted
Match Group chrooted
         ChrootDirectory %h
         X11Forwarding no
         AllowTcpForwarding no

Далее пробовал этот вариант: http://khmel.org/?p=624

/root/create_chroot_env.sh /home/usertest

И этот вариант пробовал: http://www.opennet.ru/tips/2006_sftp_ssh_chroot.shtml http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jai...

/root/make_chroot_jail.sh usertest /bin/bash /home/usertest

В обеих вариантах копируются системные папки и файлы в домашнюю директорию пользователю /home/usertest

Но не пускает через shell, не через ssh-тонель, как только ввожу пароль, ошибка:

Server unnecessarily closed network 

Nezhnayka28
() автор топика
Ответ на: комментарий от Nezhnayka28

Я не админ, поэтому толковых советов дать не смогу, могу только намекнуть, в какую сторону ещё можно погуглить:

1. В debian/ubuntu есть очень хорошая команда debootstrap, создающая chroot окружение для этих систем.

2. Вообще chroot считается недостаточно надёжным. В BSD-системах вместо него обычно используют jail, а в linux можно использовать лёгкие виртуальные машины типа xen.

aureliano15 ★★
()
Ответ на: комментарий от JB

lshell is a shell coded in Python that lets you

shell coded in Python

Ты понял что сделал? Начался эпик тред на 100500 сообщений.

anonymous
()
25 июня 2016 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.