Bug 5969 - [6.0] Доступ на чтение/выполнение к /lib/modules/
: [6.0] Доступ на чтение/выполнение к /lib/modules/
Status: NEW
: Sisyphus
(All bugs in Sisyphus/filesystem)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
: 9199 17728 30940
  Show dependency tree
 
Reported: 2005-01-26 15:21 by
Modified: 2017-08-17 14:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-01-26 15:21:24
Ядро 2.6 имеет свойство хранить симлинк на сборочную среду для ядра в
/lib/modules/*/build

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

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

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

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

А такому filesystem можно расставить Conflicts: или принудительную смену прав на
низлежаще каталоги?
------- Comment #6 From 2005-02-03 11:18:44 -------
Да, а может быть действительно в post-script'ах проводить разборки с тем, что
ниже /lib/modules/ ?
------- Comment #7 From 2005-06-20 18:55:58 -------
ну что, так и оставим ? Может к 3.0 исправим ?
------- Comment #8 From 2007-03-26 14:13:15 -------
Или к 4.0.
------- Comment #9 From 2007-12-08 14:33:42 -------
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 From 2011-06-09 01:39:17 -------
Или к 6.0.
------- Comment #11 From 2013-08-15 17:26:03 -------
Никто так и не предложил proof of concept регулятора.
------- Comment #12 From 2013-08-15 17:51:25 -------
(В ответ на комментарий №11)
> Никто так и не предложил proof of concept регулятора.

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

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

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

А что им там нужно? Ссылка /lib/modules/%kversion-%flavour-%krelease/build?
------- Comment #20 From 2017-08-17 14:16:14 -------
они планируют найти в /lib/modules/`uname -r`/build хедеры для сборки модулей
для текущего ядра.