Bug 5969 - [6.0] Доступ на чтение/выполнение к /lib/modules/
Summary: [6.0] Доступ на чтение/выполнение к /lib/modules/
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: filesystem (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 30940 9199 17728
  Show dependency tree
 
Reported: 2005-01-26 15:21 MSK by Anton Farygin
Modified: 2018-09-13 19:16 MSK (History)
16 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Farygin 2005-01-26 15:21:24 MSK
Ядро 2.6 имеет свойство хранить симлинк на сборочную среду для ядра в
/lib/modules/*/build

Соответственно для сборки сторонних модулей под пользователем необходимо дать
возможность пользователю заходить в этот каталог.
Comment 1 Sergey Vlasov 2005-01-26 15:57:37 MSK
Наличие у пользователя доступа даже на чтение к файлам модулей ядра даёт
возможность заблокировать выполнение insmod или modprobe, установив на эти файлы
блокировку через flock() (для modutils) или fcntl() (для module-init-tools). Нам
это нужно?

Как вариант, можно открыть доступ к /lib/modules, но при сборке пакетов с
модулями устанавливать более жёсткие права для самих файлов модулей (сейчас там
644,root,root).
Comment 2 Anton Farygin 2005-01-26 16:02:24 MSK
И это, кстати, тоже верно. Для них вполне нормально делать 600
Comment 3 Anton Farygin 2005-02-02 22:10:57 MSK
Ну так как, исправим ?
Comment 4 Dmitry V. Levin 2005-02-03 01:26:35 MSK
Нельзя давать локальным пользователям возможности сделать DoS.

Если необходимо открыть каталог /lib/modules, то придётся придумать способ
защитить системы, работающие с теми ядрами, которые уже собраны в предположении,
что каталог /lib/modules закрыт.
Comment 5 Michael Shigorin 2005-02-03 09:47:22 MSK
(In reply to comment #4)
> Нельзя давать локальным пользователям возможности сделать DoS.

У них практически всегда остаётся старая добрая форк-бомба...

А такому filesystem можно расставить Conflicts: или принудительную смену прав на
низлежаще каталоги?
Comment 6 Anton Farygin 2005-02-03 11:18:44 MSK
Да, а может быть действительно в post-script'ах проводить разборки с тем, что
ниже /lib/modules/ ?

Comment 7 Anton Farygin 2005-06-20 18:55:58 MSD
ну что, так и оставим ? Может к 3.0 исправим ?
Comment 8 Michael Shigorin 2007-03-26 14:13:15 MSD
Или к 4.0.
Comment 9 Michael Shigorin 2007-12-08 14:33:42 MSK
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
Comment 10 Michael Shigorin 2011-06-09 01:39:17 MSK
Или к 6.0.
Comment 11 Michael Shigorin 2013-08-15 17:26:03 MSK
Никто так и не предложил proof of concept регулятора.
Comment 12 Alexey Gladkov 2013-08-15 17:51:25 MSK
(В ответ на комментарий №11)
> Никто так и не предложил proof of concept регулятора.

Что значит "proof of concept регулятора" ?
Comment 13 Michael Shigorin 2013-08-15 21:34:53 MSK
Набросок ручки для переключения поведения.
Comment 14 Michael Shigorin 2015-02-16 20:41:27 MSK
---
> Времена меняются и 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
Comment 15 Alexey Shabalin 2016-08-04 17:04:02 MSK
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
Comment 16 Alexey Shabalin 2016-08-04 17:05:17 MSK
извините, мышка дёрнулась. но всё равно ping.
Comment 17 Anton Farygin 2017-08-17 13:16:29 MSK
Дима, опять эта проблема вылезла со сборкой модулей ядра для vmware.

давайте уже это исправим.
Comment 18 Anton Farygin 2017-08-17 13:40:45 MSK
http://git.altlinux.org/tasks/187197/logs/events.1.1.log

жду approve
Comment 19 Dmitry V. Levin 2017-08-17 14:15:00 MSK
(In reply to comment #17)
> Дима, опять эта проблема вылезла со сборкой модулей ядра для vmware.

А что им там нужно? Ссылка /lib/modules/%kversion-%flavour-%krelease/build?
Comment 20 Anton Farygin 2017-08-17 14:16:14 MSK
они планируют найти в /lib/modules/`uname -r`/build хедеры для сборки модулей для текущего ядра.
Comment 21 Anton Farygin 2017-12-11 08:05:34 MSK
Дим, не пора ли уже открыть доступ к /lib/modules ?
Comment 22 Dmitry V. Levin 2018-03-04 03:04:14 MSK
(In reply to comment #21)
> Дим, не пора ли уже открыть доступ к /lib/modules ?

Думаю что в Сизифе уже пора: все ядра уже достаточно давно были пересбораны.
Comment 23 Anton Farygin 2018-03-04 11:15:47 MSK
Целиком поддерживаю. Сделаешь ?
Comment 24 Anton Farygin 2018-08-16 20:59:56 MSK
Ну так что, мне отправить новый filesystem в Sisyphus ?
Comment 25 Repository Robot 2018-08-29 00:12:29 MSK
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).
Comment 26 AEN 2018-08-29 01:30:25 MSK
Ура!
13 с половиной лет.
Comment 27 Anton Farygin 2018-09-01 12:13:04 MSK
Да уж, достижение... ;)
Comment 28 Lenar Shakirov 2018-09-11 17:22:28 MSK
Простите, у меня два вопроса:


(В ответ на комментарий №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
Comment 29 Michael Shigorin 2018-09-13 19:14:17 MSK
(В ответ на комментарий №28)
> Простите, у меня два вопроса:
> (В ответ на комментарий №25)
> > - Made /lib/modules readable and executable by everybody (closes: #5969).
> 2ldv: вы не против бэкпорта в p8?

Если syslog сломается ещё и в p8 -- это будет финиш.
Comment 30 Lenar Shakirov 2018-09-13 19:16:13 MSK
(В ответ на комментарий №29)
...
> Если syslog сломается ещё и в p8 -- это будет финиш.

Не не, хочу бэкпортнуть только 755 на /lib/modules, остальное мне не интересно :-)