chroot или виртуальная среда тюрьмы - для кросс-компиляции?
Я с нетерпением жду, чтобы скомпилировать для моей цели ARM на моем хосте Ubuntu.
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=31&t=8478
Вышеуказанные состояния ссылок позволяют использовать chroot и напрямую компилировать вашу программу в систему rootfile вашей цели на вашем хосте.
Некоторые предлагают использовать виртуальную среду тюрьмы, как scratchbox.
Настройка среды кросс-компиляции для конкретной целевой платформы
https://en.wikipedia.org/wiki/Chroot
The chroot mechanism is not intended to defend against intentional tampering by privileged (root) users. On most systems, chroot contexts do not stack properly and chrooted programs with sufficient privileges may perform a second chroot to break out. To mitigate the risk of this security weakness, chrooted programs should relinquish root privileges as soon as practical after chrooting, or other mechanisms – such as FreeBSD Jails - should be used instead. Note that some systems, such as FreeBSD, take precautions to prevent the second chroot attack.[1]
So i am investigating on it for few days here i am not able to understand what above statement means.
1> Какое преимущество виртуальной тюрьмы перед chroot?
2> Влияет ли chroot на все открытые терминалы или.. конкретный терминал, на котором выполняется команда?
3> Что именно мы должны использовать для кросс-компиляции Jail, например, scratch-box или chroot.
1 ответ
Википедия говорит о безопасности chroot, потому что chroot часто сравнивают с песочницей (которая не обеспечивает chroot) или другими с целью обеспечения безопасности с изоляцией.
chroot () (это системный вызов UNIX) - это процесс изменения кажущегося корневого каталога (/) к другому, указанному системным вызовом. Это означает, что если исполняемый файл chroot для /dir/target хочет получить доступ для загрузки /lib/ld-linux.so.2 (жестко заданный путь в исполняемом файле), реальный доступ будет /dir/target/lib/ld-linux.so.2
Таким образом, это означает, что каждый файл и библиотека, к которым должна обращаться программа, должны иметь свой обычный реальный путь (с префиксом / ) к корневому пути (/dir/target в этом примере). Если вы используете полную систему внутри chroot, вы в конечном итоге получите структуру каталогов, описанную в man hier но с префиксом (для программ с изолированным доступом) с путем с корневым доступом. Это также означает, что вы можете использовать разные двоичные файлы другой архитектуры (если ваш ЦП поддерживает несколько из них; это обеспечивает своего рода изоляцию).
Как вы можете видеть, глядя на chroot, основная цель не в том, чтобы обеспечить безопасность, и она используется для других целей, переключаясь с корня initramfs в Linux на смонтированный корень на диске (за исключением того, что есть процесс mount -o переехать).
Однако, как указано в статье в Википедии, некоторые реализации, такие как FreeBSD, предпочитают обеспечивать определенный уровень безопасности: например, отключение возможности создания второстепенного chroot внутри chroot. Википедия неверна, когда говорит, что chroot нужно запускать с правами root. Большинство систем сегодня имеют более детальный механизм, чем права доступа пользователей / групп.
Тюрьмы предназначены для обеспечения изоляции напрямую, это позволяет ограничить объем оперативной памяти и процессора, которые процесс может использовать; отключение общей памяти; ограничить разрешения...
Некоторые реализации (например, с командой sandbox) не предоставляют chroot. В тюрьмах есть приложения для виртуализации на уровне операционной системы или предотвращения повреждения остальной части системы при тестировании специального кода.
Если вы возьмете пример команды sandbox, вы увидите, что она не может использовать структуру альтернативного корневого каталога сама по себе.
http://www.raspberrypi.org/forums/viewtopic.php?f=31&t=8478 упоминает qemu-пользователя, который должен явно тестировать программы без необходимости помещать их на Rasberry Pi. Это отличается от виртуальных машин, потому что здесь не виртуализируется никакое оборудование: двоичные инструкции программы преобразуются в собственные, что означает, что системные вызовы обрабатываются так, как если бы программа выполнялась изначально.
Возникает необходимость использовать другую структуру корневых каталогов: имена путей некоторых общих объектных файлов являются общими для всех дистрибутивов и архитектур (например, /lib/ld-linux.so.2) Вы не можете смешивать несколько архитектур в одном бинарном файле. Если вы замените разделяемую библиотеку ее эквивалентом ARM, файлы не будут использоваться для собственных исполняемых файлов. qemu-user или вся целевая система должны быть статически скомпилированы по той же причине.
Я действительно предлагаю вам установить и настроить binfmt. Это позволит вам запускать программы, как если бы они имели одинаковую архитектуру вашего компьютера, автоматически запуская команду qemu-arm-static...
Затем вы можете скомпилировать программное обеспечение без кросс-компиляции, просто установив собственный компилятор ARM внутри вашего chroot.