Vladislav Tsibulnik <Vladislav.Tsibulnik@p238.f1.n4614.z2.fidonet.org> wrote:
> Подскажите, pls, как установить директорию, выше которой не может подниматься
> usrer, но чтобы мог запускать проги из /bin, /usr/bin, /usr/local/bin ...
> Вроде для этой цели существует cHroot, но как им пользоватся я по man-ам не
> понял.
> Пролсветите, please.
Только 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" <yura@base4.com>
Dmitry Kiselev <kdn@uven.ru> wrote in message news:4023867200@uven.ru...
>
> Есть опыт полного отсутствия 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 <artem@AM.ALEXRADIO.COM>
Reply-To: Artem Malyshev <artem@AM.ALEXRADIO.COM>
To: BUGTRAQ@NETSPACE.ORG
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 <solar@cannabis.dataforce.net>
Alex Korchmar <Alex.Korchmar@f28.n5020.z2.fidonet.org> wrote:
> А уж история с chroot вызывает у меня просто истерический смех. Солар, бедный,
> мучался с ptrace'ом, а надо-то, оказывается, всего навсего "cd .." :-P
Depends. Для chroot-в-chroot'е (то, о чем ты на самом деле говоришь)
нужен именно root (в wu.ftpd он, конечно, и есть), тогда как для ptrace
достаточно, чтобы вне chroot'а было что-то под тем же UID'ом (правда,
обязательно не менявшее UID за всю свою жизнь, иначе current->dumpable
сбросится).
А так, да, года два назад я о возможности chroot-в-chroot не подумал.
(Прямо "cd ..", как ты сказал, при правильно поставленном chroot'е,
разумеется, ничего не даст. Эффект достигается _наоборот_ углублением
исходного chroot'а и уже отсутствием "закрепления" нового.)
Вот охота потрепаться на эту тему. Есть машинка, занимающаяся буквально всем.
Под 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 с ее фигней и т.д.
Далее: вся эта фигня, настроенная как описано далее, стартует скриптом,
который 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).
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 <solar@cannabis.dataforce.net>
Vitaly E.Lavrov <lve@cit.aanet.ru> 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.
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Alex Korchmar 2:5020/28 03 Apr 99 02:36:44
Subj : Re: Сети
________________________________________________________________________________
Alexander Knyazev <sa@ccmhf.tomsknet.ru> 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)
Вот охота потрепаться на эту тему. Есть машинка, занимающаяся буквально всем.
Под 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 с ее фигней и т.д.
Далее: вся эта фигня, настроенная как описано далее, стартует скриптом,
который 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).
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)