Summary: | [6.0] Доступ на чтение/выполнение к /lib/modules/ | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Anton Farygin <rider> |
Component: | filesystem | Assignee: | placeholder <placeholder> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P2 | CC: | aen, dd1email, eostapets, evg, glebfm, ldv, legion, mike, placeholder, real.altlinux.org, rider, shaba, snejok, solo, sr, vsu |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 30940, 9199, 17728 |
Description
Anton Farygin
2005-01-26 15:21:24 MSK
Наличие у пользователя доступа даже на чтение к файлам модулей ядра даёт возможность заблокировать выполнение insmod или modprobe, установив на эти файлы блокировку через flock() (для modutils) или fcntl() (для module-init-tools). Нам это нужно? Как вариант, можно открыть доступ к /lib/modules, но при сборке пакетов с модулями устанавливать более жёсткие права для самих файлов модулей (сейчас там 644,root,root). И это, кстати, тоже верно. Для них вполне нормально делать 600 Ну так как, исправим ? Нельзя давать локальным пользователям возможности сделать DoS. Если необходимо открыть каталог /lib/modules, то придётся придумать способ защитить системы, работающие с теми ядрами, которые уже собраны в предположении, что каталог /lib/modules закрыт. (In reply to comment #4) > Нельзя давать локальным пользователям возможности сделать DoS. У них практически всегда остаётся старая добрая форк-бомба... А такому filesystem можно расставить Conflicts: или принудительную смену прав на низлежаще каталоги? Да, а может быть действительно в post-script'ах проводить разборки с тем, что ниже /lib/modules/ ? ну что, так и оставим ? Может к 3.0 исправим ? Или к 4.0. http://lists.altlinux.org/pipermail/sisyphus/2005-February/156318.html : > > >>Именно доступ обычного пользователя в /lib/modules/ и надо исправлять. > > >Кстати, а с /boot что-то делать (в идеале control(8), но Дима > > >упоминал грабли) получается? А то для простых консультаций > > >требуется отнюдь не the least privilege... > > А ты багу повесь, обсудим. > > А в ту же осмысленно? Подумал и решил сперва сюда, бо уже не > помню, что именно мешало control-изации (склерозм -- штука > страшная, что /обсуждалось/ -- помнишь, а вот /как/...). Мешало control-изации то, что называется проблемой "яйцо или курица": у пакета filesystem не должно быть %pre-скрипта, но для control-изации нужен %pre-скрипт. > > Зачем это делал Дима в свое время, я думаю и уже он не помнит > > ;-) > > Я так не думаю (c) 1. Доступ к файлам /boot/{System.map,vmlinuz}-`uname -r` даёт возможность узнать адреса объектов ядра, что облегчает атаку на ядро. 2. Конфигурация grub'а хранится в /boot, и я помню, что раньше были проблемы в поддержании правильных прав доступа к ней. -- ldv http://lists.altlinux.org/pipermail/sisyphus/2005-February/156328.html : Меня назовут извращенцем, но можно попробовать сделать финт ушами -- побить filesystem на filesystem, filesystem-control и filesystem-lsb, в последний унеся нелюбимые многими /srv и компанию, а из первого во второй перенеся по крайней мере те каталоги, которые хорошо бы control'ировать, _но_ без которых можно поставить достаточно системы для отработки %pre. Загвоздкой являются ядро и grub, но ведь их никто не требует (из этого "достаточно", по крайней мере)? -- mike Или к 6.0. Никто так и не предложил proof of concept регулятора. (В ответ на комментарий №11) > Никто так и не предложил proof of concept регулятора. Что значит "proof of concept регулятора" ? Набросок ручки для переключения поведения. --- > Времена меняются и modutils и module-init-tools у нас не используются. > Сейчас модули грузятся libkmod, которая не использует fcntl. Да, libkmod не занимается блокировкой файлов модулей, там все просто: open O_RDONLY mmap PROT_READ MAP_PRIVATE finit_module (с разновидностями вида gzdopen/gzread с последующим init_module, если поддерживаются сжатые модули). В ушедшем module-init-tools тоже на авось: open O_RDONLY read в цикле init_module > Я думаю, что описанная в баге проблема должна быть обсуждена ещё раз. Давайте обсудим. Очевидно, что потенциальный DoS путем блокировки файла модуля сейчас уже не реализуем. -- ldv --- http://lists.altlinux.org/pipermail/devel/2014-November/199266.html ping finit_module (с разновидностями вида gzdopen/gzread с последующим init_module, если поддерживаются сжатые модули). В ушедшем module-init-tools тоже на авось: open O_RDONLY read в цикле init_module > Я думаю, что описанная в баге проблема должна быть обсуждена ещё раз. Давайте обсудим. Очевидно, что потенциальный DoS путем блокировки файла модуля сейчас уже не реализуем. -- ldv --- http://lists.altlinux.org/pipermail/devel/2014-November/199266.html извините, мышка дёрнулась. но всё равно ping. Дима, опять эта проблема вылезла со сборкой модулей ядра для vmware. давайте уже это исправим. (In reply to comment #17) > Дима, опять эта проблема вылезла со сборкой модулей ядра для vmware. А что им там нужно? Ссылка /lib/modules/%kversion-%flavour-%krelease/build? они планируют найти в /lib/modules/`uname -r`/build хедеры для сборки модулей для текущего ядра. Дим, не пора ли уже открыть доступ к /lib/modules ? (In reply to comment #21) > Дим, не пора ли уже открыть доступ к /lib/modules ? Думаю что в Сизифе уже пора: все ядра уже достаточно давно были пересбораны. Целиком поддерживаю. Сделаешь ? Ну так что, мне отправить новый filesystem в Sisyphus ? filesystem-2.3.17-alt1 -> sisyphus: Tue Aug 28 2018 Dmitry V. Levin <ldv@altlinux> 2.3.17-alt1 - Moved /etc/syslog.d from syslog-common to filesystem. - Made /lib/modules readable and executable by everybody (closes: #5969). - Added libx32 directories on x86_64 and x32 systems (by Ivan Zakharyaschev). - Added lib32 directories on %e2k (thx Ivan Zakharyaschev). - Added %ghost /run/lock/, marked /var/lock/ and /var/lock/* as %ghost (by Alexey Shabalin). Ура! 13 с половиной лет. Да уж, достижение... ;) Простите, у меня два вопроса: (В ответ на комментарий №25) ... > - Made /lib/modules readable and executable by everybody (closes: #5969). ... 2ldv: вы не против бэкпорта в p8? (В ответ на комментарий №22) > (In reply to comment #21) > > Дим, не пора ли уже открыть доступ к /lib/modules ? > > Думаю что в Сизифе уже пора: все ядра уже достаточно давно были пересбораны. 2all: Может стоит удалить эти ядра из p8? # rpm -qp --lastchange altrepos/p8/branch/x86_64/RPMS.classic/kernel-image-el7-def-3.10.0-alt9.x86_64.rpm | head -n1 * Ср июн 25 2014 Led <led@altlinux.ru> 3.10.0-alt9 # rpm -qp --lastchange altrepos/p8/branch/x86_64/RPMS.classic/kernel-image-el-def-2.6.32-alt25.x86_64.rpm | head -n1 * Пт июн 20 2014 Led <led@altlinux.ru> 2.6.32-alt25 (В ответ на комментарий №28) > Простите, у меня два вопроса: > (В ответ на комментарий №25) > > - Made /lib/modules readable and executable by everybody (closes: #5969). > 2ldv: вы не против бэкпорта в p8? Если syslog сломается ещё и в p8 -- это будет финиш. (В ответ на комментарий №29) ... > Если syslog сломается ещё и в p8 -- это будет финиш. Не не, хочу бэкпортнуть только 755 на /lib/modules, остальное мне не интересно :-) |