> и то, и другое. и проверка на выход из загончика, и проверка
> на наличие прав на каталог. потому как я не вижу фундаментальной
> разницы между chdir и fchdir, разница только в нюансах передачи имени
> каталога. соответственно, и проверки должны быть одинаковые.Проверка на наличие прав и сейчас производится для chdir и fchdir почти одинаково, с небольшой разницей в моменте проверки прав на родительские директории в пути.
Например, если отобрать у other users права на чтение-поиск в /, то и fchdir на её дескриптор (допустим, его открыли до смены прав на /) провалится с EACCES. Но такая проверка никак не запрещает побег из chroot. А значит, нужно добавить проверку на доступность директории в chroot-окружении, как уже сделано в Grsecurity и NetBSD. Если вы предлагаете дополнительные проверки, то какие, и в каких конкретных ситуациях они будут полезны?
> и на любой fd после смены юзера, кстати. я не считаю правильным,
Ну вот это и разрушит модель привилегий, сильно ограничив применимость chroot и вообще сброса привилегий root до обычного пользователя. Непривилегированные процессы не смогут обращаться к ресурсу, который ранее требовал root-привилегий только при открытии и до начала обработки недоверенных данных, а теперь стал требовать их всегда => больше кода станет работать от рута, либо привилегии доступа к ресурсам придётся кардинально *снизить*.
> что после смены юзера открытые файлы остаются доступными без проверок. да,
> придётся немного переделать программы — передать конфиги и прочее во владение
> ограниченого юзера. оно так даже лучше будет.
Я не вижу в этих переделках смысла и пользы. Только вред и адское бремя на плечи разработчиков и пользователей. Ради чего именно? Можете привести конкретные примеры?
> а оверхэд мизерный — всего лишь флажок «проверку прошёл», который скидывается
> при смене *uid, и проверяется одним сравнением при операциях с fd.
> ну, ясно, думаю.
Оверхед огромный, потому как структура-дескриптор не находится во владении какого-либо процесса. Все обращаются к ней по указателям. И при каждом read, write, lseek, recv, send и т.д. будет проходить проверка. Это вообще за гранью добра и зла, выражаясь мягко.
> а по-моему, lxc получше будет.
Дело ваше. :)
> вообще-то именно потому, что безопасен. дом монтируется с noexec, в системные места
> писать нельзя. сплойты, конечно, не исключены, но сложны и закрываются апдейтами.
> и так далее. пингвинус именно что безопаснее, чем винда.
Ха. В "системные места" и в винде нельзя писать, начиная с первых версий NT. /home не монтируется с noexec ни в одном из популярных дистрибутивов, но даже если бы, это не дало бы практически ничего. Сложность написания эксплойтов под линукс гораздо ниже, чем для висты и семёрки, из-за менее эффективных механизмов защиты от эксплуатации. Апдейтами закрываются только публично известные уязвимости с задержкой в несколько дней, а то и недель (почитайте oss-security и Full-Disclosure - вас ждёт неприятный сюрприз). "И так далее" - это дырявое ядро, сложность написания эксплойтов под которое с появлением фреймворков приблизилась к тривиальной, а также отсутствие сколько-нибудь эффективной инфраструктуры для реактивной борьбы с известными угрозами (беспечность и наивность пользователя - взломщику в помощь). Сложность поиска уязвимостей также значительно ниже, чем в висте и семёрке. Единственное, в чём линукс впереди - это охват и автоматизация обновлений, но с ростом популярности и потребности в приложениях под Wine это достоинство начинает теряться.
