The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

chroot telnet (security chroot telnet)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: security, chroot, telnet,  (найти похожие документы)
_ RU.UNIX.BSD (2:5077/15.22) _____________________________________ RU.UNIX.BSD _ From : Dmitry Kiselev 2:5020/400 21 Mar 99 18:57:06 Subj : chroot telnet ________________________________________________________________________________ From: Dmitry Kiselev <[email protected]> Vladislav Tsibulnik <[email protected]> wrote: > Подскажите, pls, как установить директорию, выше которой не может подниматься > usrer, но чтобы мог запускать проги из /bin, /usr/bin, /usr/local/bin ... > Вроде для этой цели существует cHroot, но как им пользоватся я по man-ам не > понял. > Пролсветите, please. inetd.conf(и так далее): -telnet stream tcp nowait root /usr/libexec/telnetd telnetd +telnet stream tcp nowait root /usr/libexec/telnetd /usr/sbin/chroot /hole telnetd Только user-у для работы нужны будут бинарники с либами, соотв-но. Дальше, надеюсь, понятно. -- With Best Regards, Dmitry Kiselev (http://www.kedr.uz) http://messages.to/kdn for 8464545 --- ifmail v.2.14dev3 * Origin: Center of Telecommunications, UlSU, Simbirsk, Rus (2:5020/400) _ RU.UNIX.BSD (2:5077/15.22) _____________________________________ RU.UNIX.BSD _ From : Yura Pismerov 2:5020/400 23 Mar 99 08:15:52 Subj : chroot ________________________________________________________________________________ From: "Yura Pismerov" <[email protected]> Dmitry Kiselev <[email protected]> wrote in message news:[email protected]... > > Есть опыт полного отсутствия suid-ных программ под chrooted enviroment. > Hо это обрезание функиональности. Истину надо искать где-то посередине, IMHO. ftp://ftp.simtel.ru/pub/unix/bwm/ush.tar.gz Hе оно ? > > -- > With Best Regards, Dmitry Kiselev (http://www.kedr.uz) > http://messages.to/kdn for 8464545 --- ifmail v.2.14dev3 * Origin: Cyber Genie Inc. (2:5020/400) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Alex Korchmar 2:5020/28 27 Mar 99 14:54:20 Subj : и еще о chroot ________________________________________________________________________________ Hi All! кушайте, не обляпайтесь. [ This is a repost of the following article: ] [ From: Alex Korchmar ] [ Subject: и еще о chroot ] [ Newsgroups: fido7.dig.linux ] =Original Message Follows==== From: Artem Malyshev <[email protected]> Reply-To: Artem Malyshev <[email protected]> To: [email protected] Subject: Re: another ftp exploit (fwd) Date: Fri, 26 Mar 1999 14:08:25 +0200 > /* To break chroot we have to... > > fd = open ( ".", O_RDONLY ); > mkdir ( "hax0r", 0666 ); > chroot ( "hax0r" ); > fchdir ( fd ); > for ( i = 0; i < 254; i++ ) > chdir ( ".." ); > chroot ( "." ); > > */ Too complex for standart linux All we have to do to break chroot is: mkdir("/sh"); // we already have string "/sh" in memory as a part of // "/bin/sh" chroot("/sh"); chroot("../../../../../../../../../"); // a number of "../" here, // I used 0x10 Last string can be built is stack with a simple loop Tested on linux 2.2.1 -am --- ifmail v.2.14.os-p2 * Origin: Down System -2 (2:5020/28@fidonet) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Solar Designer 2:5020/400 05 Apr 99 08:39:20 Subj : chroot ________________________________________________________________________________ From: Solar Designer <[email protected]> Alex Korchmar <[email protected]> wrote: > А уж история с chroot вызывает у меня просто истерический смех. Солар, бедный, > мучался с ptrace'ом, а надо-то, оказывается, всего навсего "cd .." :-P Depends. Для chroot-в-chroot'е (то, о чем ты на самом деле говоришь) нужен именно root (в wu.ftpd он, конечно, и есть), тогда как для ptrace достаточно, чтобы вне chroot'а было что-то под тем же UID'ом (правда, обязательно не менявшее UID за всю свою жизнь, иначе current->dumpable сбросится). А так, да, года два назад я о возможности chroot-в-chroot не подумал. (Прямо "cd ..", как ты сказал, при правильно поставленном chroot'е, разумеется, ничего не даст. Эффект достигается _наоборот_ углублением исходного chroot'а и уже отсутствием "закрепления" нового.) -- /sd --- ifmail v.2.14dev3 * Origin: DataForce ISP (2:5020/400) _ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _ From : Cyril Rotmistrovsky 2:463/59.60 10 Apr 99 19:45:58 Subj : chrooted services ________________________________________________________________________________ Salut! Вот охота потрепаться на эту тему. Есть машинка, занимающаяся буквально всем. Под Linuxом 2.0.36 -> [2.2.x], glibc 2.0.7. Хочется вынести некоторые классы пользователей куда-нибудь нафиг с нее. Другую при этом выделять не очень-то и получается. А вынести пользователей хочется не секьюрити ради, а для раздельного администрирования. Фактически вынести хочется pop3 и smb-пользователей. Ради чего хочу: 1) Создать разделы с m.p. /vm/etc/, /vm, /vm/tmp/, и по необходимости - /vm/var/spool/ для mail и mqueue, /vm/var/samba с ее фигней и т.д. 2) Заполнить /mnt/vm/dev всякими null, zero, pty* (?), console (?). 3) Смонтировать proc в /vm/proc (работает). 4) Уложить в /vm/lib libc, libdl, libm, ld.so, libcrypt, libdb (?), libgdbm (?), libresolv; может, еще что понадобится... 5) В /vm/bin: sh->ash (боюсь, без него плохо будет), [, ls, hostname (?). 6) В /vm/sbin: pop3d, smbd, nmbd, tcpd, inetd, syslogd, ldconfig, линки на них откуда надо (/vm/usr/{sbin,bin,lib}) - по настройкам смотреть. 7) В /vm/etc: passwd, shadow, group, nsswitch.conf, resolv.conf, profile, hosts.{allow,deny}, inetd.conf, ld.so.conf, lmhosts, smbpasswd, smbusers, protocols, services, syslog.conf. Вроде, ничего не забыл? Далее: вся эта фигня, настроенная как описано далее, стартует скриптом, который chrootится в /vm, а затем запускает сервисы как положено, не забыв про [/vm]/sbin/ldconfig . А именно: I) inetd, который ловит pop3. II) nmbd/smbd III) syslogd - вот с ним вопрос: будет ли он уживаться с ``корневым''? Дело в том, что /dev/log - сокет, а потому запись в /dev/log и [/vm]/dev/log - запись в разные потоки, так что с этой т.з. все ОК, а логгингом ядерных сообщений ведает klogd, который в vm пускаься не будет... так что все должно быть OK. IV) в корневом sendmail.cf указывается LUSER_RELAY как... и вот тут есть варианты: a) мог бы быть mailer типа mail.local, только берущий вместо /etc/passwd /vm/etc/passwd, и кладущий почту в боксы в /vm/var/spool/mail b) может быть обычный mail.local, только chrootящийся. c) можно было бы организовать нечто типа smtp-транспорта с редиректом портов ( ;] ) d) или вообще uucp. ;) V) В /vm/etc/{passwd,group} заводятся пользователи со своим диапазоном uid/gid (не пересекающимся с `корневыми', кроме, естественно, root, mail. VI) Hу, всякие /vm/etc/{passwd,group,shadow,smb*} vm group - writeable, а группа vm - корневая, и входят в нее `корневые' пользователи. Это дает возможность не складывать в vm кучу лишних утилит и администирить ее как бы снаружи. Разве что придется для удобства им написать vmls, vmchmod, vmchown (берущие имена пользователей/групп из /vm/etc/passwd). VII) Разумеется, /vm монтируется ro, /vm/*/ - noexec. /vm/etc - отдельным разделом (!), noexec (во избежание). VIII) Было бы красиво иметь все-таки /vm не отдельным разделом, чтобы /vm/{lib,sbin}/* были хардлинками на /{lib,sbin}/* - ради экономии памяти. Естественно, это нехорошо из других соображений... Получается, что `корневая' группа vm имеет возможность управлять пользователями виртуальной железки, не имея рутовых прав. Внимание, вопрос: кто что по этому поводу думает? Главное: не усложню ли я себе этим жизнь? (может, я забыл кучу мелочей, которые в последний момент понадобятся? и так уже chrootящиеся mail.local, chmod/chown/ls меня смущают (на настройку всего этого хочется потратить не больше трех--четырех часов на полигоне и двух часов потом на рабочей машине на ходу). -- Soiree, Cyril. P.S. Может, вместо этого взять pop3 и smb с аутентификацией у sql-сервера? ;) Одно `но': квоты должны быть. Да и самбу учить придется самому... впрочем, pop3, возможно, тоже. : A woman can never be too rich or too thin. --- Gnus v5.5/XEmacs 20.4 - "Emerald" * Origin: Microsoft free station (2:463/59.60@fidonet) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Solar Designer 2:5020/400 03 Apr 99 06:07:26 Subj : и еще о chroot ________________________________________________________________________________ From: Solar Designer <[email protected]> Vitaly E.Lavrov <[email protected]> wrote: > Вопрос: что делать с cwd ? Точнее что делать с ним если он указывает > выше корня ? (wu-ftpd совсем не беспокоится о нем - факт! Так что дырки > в нем могут быть еще круче) Hеправда: /* We MUST do a chdir() after the chroot. Otherwise the old current * directory will be accessible as "." outside the new root! */ [...] if (chroot(pw->pw_dir) < 0 || chdir("/") < 0) { reply(530, "Can't set guest privileges."); goto bad; } Если кратко: при всем моем неуважении к wu-ftpd и 20 порту в FTP (вот, кстати, где capabilities могут помочь), в возможности выхода из chroot он не виноват. А виноваты либо стандарты, либо никто (т.к. как его ни ограничивай проверками по типу в securelevel, с возможностью посылать сигналы во вне ничего путного не сделать). Если кто не понял: wu-ftpd работает под root'ом, остальное следствия. Hа этом хотелось бы остановиться и не повторять одну из многочисленных дискуссий в comp.security.unix, где это почти FAQ. -- /sd --- ifmail v.2.14dev3 * Origin: DataForce ISP (2:5020/400) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Alex Korchmar 2:5020/28 03 Apr 99 02:36:44 Subj : Re: Сети ________________________________________________________________________________ Alexander Knyazev <[email protected]> wrote: >> ну а с линуксом? Вот мне мешает багованность wu-ftpd, но взять лом наперевес >> и побежать писать свой мне как-то не светит. И от academ.com, похоже, >> хрен мы чего дождемся. И что делать прикажешь? Pro ставить? (null) AK> Возьми NcFTPd. Коммерческий продукт. Очень стабилен. Взять можно с насколько я помню, в нем та же самая дыра. (что наводит на крайне неприятные мысли о его авторе) AK> http://www.ncftp.com. Да, и чем ProFTPD не нравится? Потом, есть еще AK> BeroFTPD - тоже рулезный демон. Свет клином не сошелся на wu-ftpd, тем, что оба дрянь, второй - содран с wu. И содраны людьми, которые вообще не умеют писать программы. Вы не видели, как оно падает в core? Заходите, покажу. Жаль, не могу показать скриншоты с (null) в выдаче ftp.gnu.org - они заткнули эту дырку. AK> не так ли? не так. wu-ftpd - единственный, который сделан не пионерским шапкозакидательским способом. К сожалению, поддержки мы не дождемся, майнтейнеры почили в бозе. м >> на gnu.org видел? Вот такие руки у писателей. Если там внутри нет десятка >> дырок, то я ящерица с двумя хвостами. >> >> Линуксы - ни на грош. OpenBSD всем хороша, но непригодна для сервера и >> судьба у нее вполне предсказуемая - деньги закончатся, и привет. AK> Как насчет NetBSD? насколько я знаю - ничем особенно не хороша. > Alex --- ifmail v.2.14.os-p2 * Origin: Down System -2 (2:5020/28@fidonet) _ RU.UNIX (2:5077/15.22) _____________________________________________ RU.UNIX _ From : Cyril Rotmistrovsky 2:463/59.60 10 Apr 99 19:45:58 Subj : chrooted services ________________________________________________________________________________ Salut! Вот охота потрепаться на эту тему. Есть машинка, занимающаяся буквально всем. Под Linuxом 2.0.36 -> [2.2.x], glibc 2.0.7. Хочется вынести некоторые классы пользователей куда-нибудь нафиг с нее. Другую при этом выделять не очень-то и получается. А вынести пользователей хочется не секьюрити ради, а для раздельного администрирования. Фактически вынести хочется pop3 и smb-пользователей. Ради чего хочу: 1) Создать разделы с m.p. /vm/etc/, /vm, /vm/tmp/, и по необходимости - /vm/var/spool/ для mail и mqueue, /vm/var/samba с ее фигней и т.д. 2) Заполнить /mnt/vm/dev всякими null, zero, pty* (?), console (?). 3) Смонтировать proc в /vm/proc (работает). 4) Уложить в /vm/lib libc, libdl, libm, ld.so, libcrypt, libdb (?), libgdbm (?), libresolv; может, еще что понадобится... 5) В /vm/bin: sh->ash (боюсь, без него плохо будет), [, ls, hostname (?). 6) В /vm/sbin: pop3d, smbd, nmbd, tcpd, inetd, syslogd, ldconfig, линки на них откуда надо (/vm/usr/{sbin,bin,lib}) - по настройкам смотреть. 7) В /vm/etc: passwd, shadow, group, nsswitch.conf, resolv.conf, profile, hosts.{allow,deny}, inetd.conf, ld.so.conf, lmhosts, smbpasswd, smbusers, protocols, services, syslog.conf. Вроде, ничего не забыл? Далее: вся эта фигня, настроенная как описано далее, стартует скриптом, который chrootится в /vm, а затем запускает сервисы как положено, не забыв про [/vm]/sbin/ldconfig . А именно: I) inetd, который ловит pop3. II) nmbd/smbd III) syslogd - вот с ним вопрос: будет ли он уживаться с ``корневым''? Дело в том, что /dev/log - сокет, а потому запись в /dev/log и [/vm]/dev/log - запись в разные потоки, так что с этой т.з. все ОК, а логгингом ядерных сообщений ведает klogd, который в vm пускаься не будет... так что все должно быть OK. IV) в корневом sendmail.cf указывается LUSER_RELAY как... и вот тут есть варианты: a) мог бы быть mailer типа mail.local, только берущий вместо /etc/passwd /vm/etc/passwd, и кладущий почту в боксы в /vm/var/spool/mail b) может быть обычный mail.local, только chrootящийся. c) можно было бы организовать нечто типа smtp-транспорта с редиректом портов ( ;] ) d) или вообще uucp. ;) V) В /vm/etc/{passwd,group} заводятся пользователи со своим диапазоном uid/gid (не пересекающимся с `корневыми', кроме, естественно, root, mail. VI) Hу, всякие /vm/etc/{passwd,group,shadow,smb*} vm group - writeable, а группа vm - корневая, и входят в нее `корневые' пользователи. Это дает возможность не складывать в vm кучу лишних утилит и администирить ее как бы снаружи. Разве что придется для удобства им написать vmls, vmchmod, vmchown (берущие имена пользователей/групп из /vm/etc/passwd). VII) Разумеется, /vm монтируется ro, /vm/*/ - noexec. /vm/etc - отдельным разделом (!), noexec (во избежание). VIII) Было бы красиво иметь все-таки /vm не отдельным разделом, чтобы /vm/{lib,sbin}/* были хардлинками на /{lib,sbin}/* - ради экономии памяти. Естественно, это нехорошо из других соображений... Получается, что `корневая' группа vm имеет возможность управлять пользователями виртуальной железки, не имея рутовых прав. Внимание, вопрос: кто что по этому поводу думает? Главное: не усложню ли я себе этим жизнь? (может, я забыл кучу мелочей, которые в последний момент понадобятся? и так уже chrootящиеся mail.local, chmod/chown/ls меня смущают (на настройку всего этого хочется потратить не больше трех--четырех часов на полигоне и двух часов потом на рабочей машине на ходу). -- Soiree, Cyril. P.S. Может, вместо этого взять pop3 и smb с аутентификацией у sql-сервера? ;) Одно `но': квоты должны быть. Да и самбу учить придется самому... впрочем, pop3, возможно, тоже. : A woman can never be too rich or too thin. --- Gnus v5.5/XEmacs 20.4 - "Emerald" * Origin: Microsoft free station (2:463/59.60@fidonet)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру