Pull to refresh

Comments 34

уж лучше тогда linux containers (lxc), в убунте 12.04 очень приятно все реализовано.
А какие там новости в области LXC по сравнению с 11.10? Где почитать порекомендуете именно про это?
Вы написали, что лучше, а почему не написали.
Мы используем Proxmox для таких целей. Проблем почти нет )
Да, простите, не углядел с телефона ))
С lxc не всё так гладко в плане безопасности. В зависимости от настроек, контейнер либо может перемонтировать родительскую fs в read-only, либо не может установить свой hostname, например. Т.к. это регулируется с помощью одного capability CAP_SYS_ADMIN. И я не удивлюсь, если и LXC подвержен такой атаке (правда, есть ещё CAP_SYS_CHROOT, который тоже можно отобрать).
А в lxc нет такой проблемы, то есть не общий /proc?
proc по-умолчанию точно не общий.
М-м… Интересно, как обстоят дела с зонами Solaris и BSD Jail, просто ни когда с ними не работал и понятия не имею как они устроены.
Зоны в Солярке — полноценные виртуальные машины со своими дисками
Я так думаю, что достаточно не давать рута в chroot-е. «Использовать для построения сборочных ферм виртуализацию» не обязательно в таком случае.
А классика — cd / & mkdir /tmp & chroot /tmp & cd ../../../../../… & chroot. (или как-то так, точно уже не помню) не работает больше?
Работает:
fd = open(".", O_RDONLY);
mkdir("./tmp", 0700);
chroot("./tmp");
fchdir(fd);
while (...) chdir("..");
А кто-нибудь может обьяснить смысл этого? Я не понимаю, каким образом происходит переход на host'вый / простым cd ../ в chroot'овом окружении.
chroot делает dot-dot в новом корне эквивалентным просто dot, т.е. лишает возможности подняться из-под нового корня наверх. Если процесс каким-то образом получил текущую директорию, которая _не_ под новым корнем, то chroot не помешает подняться из этой директории до настоящего корня. Есть несколько способов получить такую текущую директорию. Один основан на том, что согласно POSIX, chroot не меняет текущую директорию, поэтому если мы из-под chroot сделаем еще один chroot на поддиректорию текущей, то наша текущая директория будеи выше корня и см. выше. Второй способ (приведенный мной) работает для тех старых UNIX-ов, где chroot «улучшили», чтобы он менял текующую директорию на новый корень. Идея остается той же: делаем новый chroot и возвращаемся наверх при помощи fchdir. Как сказал по этому поводу Алан Кокс «If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means».
Спасибо, весьма познавательно.
+1 к карме. ;)
может и не злодей вовсе, rm -fr /, кто-же знал о /proc/1/cwd :)
Интересно… что такое chroot они знают, а что такое бекапы, version control и прочие фишки для хранения кода для разработчиков они не в курсе?
Всё это на отдельных серверах.
Если бы герой вашей статьи, вместо бредовых рассуждений на 3 страницы, набрал в консоли man chroot и узрел строки:

> This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a «chroot jail» by doing:
> mkdir foo; chroot foo; cd…

он бы сэкономил немало времени и себе, и читателям.
Во FreeBSD этого предупреждения нет — это значит, что ман неполон или что FreeBSD к этому устойчива?
>… и после увольнения сотрудника «икс» вы просыпаетесь — а на сервере девственно >чистый жёсткий диск. Злодей уничтожил труды разработчиков, работа встала.
Я одного не понял. Его что, после увольнения от ресурсов не отключили???
Про это часто забывают :) Помню, когда я увольнялся с одной компании, три месяца (!) никто даже не дернулся поменять пароль рута на всех машинах, подконтрольных мне… Поменяли только после того, когда я зашел на консоль со своей домашней машины, соответственно, светанув IP — и не придумав ничего умнее, удалил last access IP :)) я это к тому, что человеческий фактор и беспечность, к сожалению, никуда не деваются. Просто взяли и забыли его отключить :)
Если не секрет, что подвигло уволенного работника на такие действия?
UFO just landed and posted this here
А если uid в chroot будет такой же как uid вне chroot, то выйдя так из chroot он сможет править чужие папки?
чтобы вылезти из chroot методом, описанным в посте, нужен root, у которого uid=1 на любой системе. При вылезании же вылезаешь как root с тем же uid=1, соответственно, можешь делать всё, что в голову взбредёт.

Метод вылезания через cd ../../../../ не пробовал, так что насчёт этого метода не в курсе: думаю, при совпадении uid можно будет редактировать файлы данного uid.
Sign up to leave a comment.

Articles