Повышение безопасности с помощью многоэкземплярности директорий

Мдя .. опять идею вынесли из Plan9 :) в котором для КАЖДОГО процесса свой namespace :)

Гм. А зачем это?

niels:~$ ls -la /tmp/ | grep X0
-r--r--r-- 1 root root 11 2008-05-14 10:24 .X0-lock
niels:~$ LANG=C rm /tmp/.X0-lock
rm: remove write-protected regular file `/tmp/.X0-lock'? y
rm: cannot remove `/tmp/.X0-lock': Operation not permitted
niels:~$ echo 123 > /tmp/test.test
niels:~$ cat /tmp/test.test
123
niels:~$ chmod 600 /tmp/test.test
niels:~$ sudo chown root.root /tmp/test.test
niels:~$ LANG=C cat /tmp/test.test
cat: /tmp/test.test: Permission denied

Я что-то пропустил в этой жизни?

Пропустил, в школе недоучился.

Операции "echo", "chmod", "chown" разнесены по времени. Если бы они выполнялись в одной транзакции, то и проблемы бы не было.

И ещё не учитываешь, что это ТЫ знаешь, что нужно сделать chmod, а ДРУГИЕ пользователи могут и не знать.

подскажите где почитать про то как chroot к ssh прикрутить - входишь по ssh и попадаешь в свой chroot

Ну вот php, например, у многих хостеров скидывает по умолчанию сессии в /tmp в виде sess_<SID>. Т.е. любой пользователь может легко узнать чужой sid. И chmod не спасет :)

Чем не устраивает починка файла /etc/passwd? Там можно любой шелл задавать, в том числе и chroot :)

> Т.е. любой пользователь может легко узнать чужой sid.

И что ему это дает? :)

Про школу аргумент мимо кассы.

Про разнесение по времени - никто не мешал мне создать пустой файл, сделать chmod, а уж потом писать туда что хочу.

Про пользователей... Давно последний раз писал ручками в /tmp? Мне всегда казалось, что туда пишут преимущественно программы. А там уже остаётся на откуп конкретного автора, что и как он туда пишет. У меня сейчас в /tmp нет ни одного файла, открытого на запись кому попало. Так что имхо особой проблемы нет.

> niels:~$ chmod 600 /tmp/test.test

Вот это Вы и пропустили. Точнее, не учитываете, что при создании временных файлов, почему-то, правилом хорошего тона считается оставлять права доступа на файл "какие получатся". Да и умаск отдельно взятые кретины меняют на что попало... :(

У меня сейчас в /tmp 43 файла. Все они открыты на запись только владельцу. Есть несколько .lock файлов, с pid'ами внутри, они открыты всем на чтение, что логично. ЧЯДНТ?

Ну, например, перебрав в скрипте домены и sidы залогиниться на какой-нибудь форум, а если сессия окажется админской, то вообще хорошо :)

> Мдя .. опять идею вынесли из Plan9 :) в котором для КАЖДОГО процесса свой namespace :)

Этож наоборот хорошо. Если постепенный переход в сторону Plan 9, с сохранением работоспособности софта и дальше будет - все от этого только выиграют.

> Ну, например, перебрав в скрипте домены и sidы залогиниться на какой-нибудь форум ...

А можно с этого места поподробнее? Вот я захожу на сервак к своему хостеру и вижу кучу файлов типа sess_<SID> в /tmp. Как мне залогиниться на "какой-нибудь" форум? :)

>Чем не устраивает починка файла /etc/passwd? Там можно любой шелл задавать, в том числе и chroot :)

Можно Howto для тупых ???

>У меня сейчас в /tmp 43 файла. Все они открыты на запись только владельцу. Есть несколько .lock файлов, с pid'ами внутри, они открыты всем на чтение, что логично. ЧЯДНТ?

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

>Ну, например, перебрав в скрипте домены и sidы залогиниться на какой-нибудь форум, а если сессия окажется админской, то вообще хорошо :)


Apache запущен для каждого домена под его uid:gid + многоэкземплярность.
пробуйте-пробуйте перебрать в скрипте домены и sidы :-)

1. SIDы знаете
2. Узнаете список сайтов/доменов на сервере. Цель атаки знаете.
3. Находите среди них допустим phpBB.
4. В post запросе поочередно подставляете все sid'ы

> Про разнесение по времени - никто не мешал мне создать пустой файл, сделать chmod, а уж потом писать туда что хочу.

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

> Давно последний раз писал ручками в /tmp?

Да, приходится периодически писАть в /tmp руками. И не всегда вспоминаешь о защите, особенно второпях. Если работают скрипты, то всегда использую mktemp.

> А там уже остаётся на откуп конкретного автора, что и как он туда пишет.

Вот именно. Ещё раз говорю - учитывай человеческий фактор, нет идеальных людей.

>Apache запущен для каждого домена под его uid:gid + многоэкземплярность

Это далеко не так. Апач у многих (самых-самых популярных %) работает от пользователя apache или www. Да и роли это не играет.

> 2. Узнаете список сайтов/доменов на сервере.

А как? :)

>Apache запущен для каждого домена под его uid:gid + многоэкземплярность

Это далеко не так. Апач у многих (самых-самых популярных %) работает от пользователя apache или www. Да и роли это не играет.

> На месте создаваемого файла может быть чужая символическая ссылка

Так я и не говорил не проверять, я изложил примерную последовательность действий.

Но ладно, согласен. Пусть будет. В любом случае лучше перебдеть, чем недобдеть ;)

А в Слаке это работает?

Слишком у Вас много вопросов %) Это подозрительно, решили стать хакером.

Можно воспользоваться domainsdb.net (но он вроде закрылся).
www.domaintools.com. - тоже например. Тажке можно просто походить по серверу и посмотреть названия папок (маловероятно). Хотя Plesk например, дает такую возможность.

в нетбсд для этой цели используются magic symlinks.

>Можно Howto для тупых ???

sudo vim /etc/passwd :)

>Да и роли это не играет.

если апач запущен на хостинге под apache\www для всех, то мы не только /tmp можем узреть, но и поглядеть файлы у домена соседа.

Какие-то не хорошие хостинги.

>если апач запущен на хостинге под apache\www для всех, то мы не только /tmp можем узреть, но и поглядеть файлы у домена соседа

Боюсь, Вы понятия не имеете как устроены виртуальные хостинги. То о чем вы говорите, разделено на уровне прав доступа к файлам. CGI и FastCGI запускаются через suexec и этого достаточно. mod_php же работает с правами апача (www,nobody,apache) и файлы защищаются посредством open_basedir.

Тебе жалко?

Вы коммерческие программы по *nix видели?
Они написаны так как-будто кроме них на сервере никого больше нет и не будет и часто работают из под root'a хотя им это нафиг не надо. Поубивал бы.

>Чем не устраивает починка файла /etc/passwd? Там можно любой шелл задавать, в том числе и chroot :)

Chroot environment кто создавать и обновлять будет для каждого пользователя ?
Делать больше нечего когда всего то надо /tmp и /var/tmp разделить.

> Слишком у Вас много вопросов %) Это подозрительно, решили стать хакером.

Да нет. Просто интересно, действительно ли можно так взломать сайт или только умозрительно... :)

> www.domaintools.com. - тоже например.

И что? Там какие-то тулзы типа пинга, nslookup, подбора доменных имен, еще какая-то хрень... А как узнать какие сайты хостятся на серваке? Вот возьмем конкретный сервер - fe57.masterhost.ru. Как? Хотя бы теоретически? :)

/капча: ranthed

Вот это для Вас: http://www.xakep.ru/magazine/xA/092/056/2.asp Там написано, как domaintools использовать.

>Вот возьмем конкретный сервер - fe57.masterhost.ru. Как? Хотя бы теоретически?

Я и говорю только теоретически. На практике я не буду это делать и Вам не советую. И еще ps: сайты лежат не на fe57.masterhost.ru, а на be57.masterhost.ru

>Боюсь, Вы понятия не имеете как устроены виртуальные хостинги.

Может быть, может быть...

но вот пример
http://www.opennet.ru/base/dev/apache_php_as_cgi.txt.html
suEXEC позволяет запускать скрипты от имени владельца сайта и
соответственно создавать/менять файлы, принадлежащие ему. Поэтому нет
необходимости назначать право записи группе и тем более всем. К
сожалению проблема с чтением чужих файлов остаётся.


Т.е. -> К сожалению проблема с чтением чужих файлов остаётся.

будет постепенный переход в сторону сборника костылей и подпорок с последующем забвением план9

> Вот это для Вас: http://www.xakep.ru/magazine/xA/092/056/2.asp Там написано, как domaintools использовать.

Спасибо.

> сайты лежат не на fe57.masterhost.ru, а на be57.masterhost.ru

Да, правильно. :) Кстати, domainsdb.net вроде бы работает, но на нем сейчас интересная вывеска: "Внимание ! На сервере с базой доменов произошел сбой raid-массива в результате которого базы были утеряны. Работа сайта возобновится при первой же возможности. Спасибо за понимание" :)

>Операции "echo", "chmod", "chown" разнесены по времени. Если бы они выполнялись в одной транзакции, то и проблемы бы не было.

а так:

touch file
chmod 600 file
echo 123 > file

!Запуск скрипта из suexec почти не отличается от запуска скрипта со своим uid,gid.

Вы можете прочитать файлы пользователя в его домашней директории, даже если у них права 666? Не можете. Почему? Потому что права на домашнюю директорию 700 или 750.

>Т.е. -> К сожалению проблема с чтением чужих файлов остаётся.

похоже они её решили. Ну да ладно мы вместо suexec используем itk.

man mktemp<Enter>
/EXAMPLES<Enter>

здравствуй новый геморрой, и как теперь анализировать почему у пользователя по какой-то причине нет доступа к /tmp? залезить на сервер, посмотреть что все в порядке с /tmp, потом делать grep -r tmp /etc, да? не тру.

по поводу сессий php: php_admin_value session.save_path, php_admin_value upload_tmp_dir по-моему еще никто не отменял, тем более, у вменяемы людей есть еще php_admin_value open_basedir в который / ну никак не попадает.

А что по этому поводу думает Патрег? =)

>по поводу сессий php: php_admin_value session.save_path, php_admin_value upload_tmp_dir по-моему еще никто не отменял

По умолчанию значение стоит в /tmp. Некоторые пользователи могут поменять это в .htaccess. но, к сожалению, пользуются немногие. Достаточно заглянуть в /tmp на любом хостинге и посмотреть сколько там сессий лежит.

>у вменяемы людей есть еще php_admin_value open_basedir в который / ну никак не попадает

Это тут cовсем не причем. sid сессии можно узнать вообще без php.

>По умолчанию значение стоит в /tmp. Некоторые пользователи могут поменять это в .htaccess. но, к сожалению, пользуются немногие. Достаточно заглянуть в /tmp на любом хостинге и посмотреть сколько там сессий лежит

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

Смотри, например, http://olivier.sessink.nl/jailkit/

я использовал...

>Чем не устраивает починка файла /etc/passwd? Там можно любой шелл задавать, в том числе и chroot :)

Дело в том что в /etc/passwd указан /bin/bash и он запускается УЖЕ с правами пользователя которым входишь, а для chroot нужны права root... В голову приходит только идея писать какую-то спец программу на которую ставить suid и которая быдет запускать chroot... Может есть простое и всеми давно используемое решение ???

Со мной был реальный случай, когда на форум удалось войти под админским аккаунтом благодаря известному id. Только я добрый - сказал админу про косяк)

Вообще-то, был-есть проект на сурсфорже chrootssh, а недавно в openssh приняли это дело. http://www.opennet.ru/opennews/art.shtml?num=14331

ssh sftp теперь чрутятся из коробки. (Обновите коробки :)

sshd_config: ChrootDirectory

>sshd_config: ChrootDirectory

В Debian пока нет этого sshd :(((