Автор Тема: bash-completion. не работает дополнение modprobe от юзера  (Прочитано 7726 раз)

Оффлайн wRAR

  • Завсегдатай
  • *
  • Сообщений: 469
А чем небезопасно давать любому юзеру, пусть даже "злоумышленнику", читать директорию /lib/modules? Какая sensitive информация в ней хранится?
Бинарники ядра там хранятся.

Оффлайн cobold

  • Начинающий
  • *
  • Сообщений: 9
А чем небезопасно давать любому юзеру, пусть даже "злоумышленнику", читать директорию /lib/modules? Какая sensitive информация в ней хранится?
Бинарники ядра там хранятся.

Про бинарники ядра я в курсе. Мне искренне непонятно, что в них такого, что прочитав их злоумышленник сможет как-то навредить системе. Это же те же самые бинарники, что лежат в репозитории, которые может скачать кто угодно и делать с ними все, что лицензия позволяет. Более того в том же репозитории есть исходники, из которых построены эти бинарники.


Вы абсолютно правы. Сферическим и прочим пользователям настраивать железо нужно ОДИН РАЗ (в момент установки системы или железа). На один раз можно и залогинитсья рутом. А всяким несферическим тестировщикам железа, которые по шесть раз в день меняют материнские платы в своем компе, квалификация должна позволять изменить $PATH или поведение команды su. Если не позволяет -- пусть идут в сад.

Алексей, давайте не отходить от темы. То, что в ALTLinux 4.1 Desktop не работает функциональность(частный случай оной) предоставляемая пакетом bash-completion это факт? Кейс, при котором не работает функциональность, показан? Вопрос в том исправлять ли это на мой взгляд не стоИт. Нужно как минимум сделать чтобы эта некрасивая ошибка не выскакивала. И веских доводов против того чтобы сделать "читабельным" /lib/modules "из коробки" пока не приведено. Поймите меня правильно, я ничего ни от кого не требую, т.к. для себя вопрос решил. Просто хочется чтобы дистрибутив стал дружелюбным еще и в этом нюансе.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 299
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Цитировать
Мне искренне непонятно, что в них такого, что прочитав их злоумышленник сможет как-то навредить системе.
Смотрим, например, каков реальный состав модулей ядра, потом закидываем в инет поиск по каждому модулю - нет-ли на него эксплоита, что-бы через него получить привилегии root. Бред конечно, но бережёного бог бережёт.
Конечно перестраховка, но задача у хакера - загрузить свой модуль, какое-бы он имя не носил. А хакеры в основном виндузятники, работают по готовым рецептам. По памяти модули не помнят. Зачем им лишняя информация о составе ядра ?

Оффлайн Vitls

  • Глобальный модератор
  • *****
  • Сообщений: 372
  • Идиотизм вечен!
    • Linux. OpenSource. Life.
    • Email
Алексей, давайте не отходить от темы. То, что в ALTLinux 4.1 Desktop не работает функциональность(частный случай оной) предоставляемая пакетом bash-completion это факт? Кейс, при котором не работает функциональность, показан? Вопрос в том исправлять ли это на мой взгляд не стоИт. Нужно как минимум сделать чтобы эта некрасивая ошибка не выскакивала. И веских доводов против того чтобы сделать "читабельным" /lib/modules "из коробки" пока не приведено. Поймите меня правильно, я ничего ни от кого не требую, т.к. для себя вопрос решил. Просто хочется чтобы дистрибутив стал дружелюбным еще и в этом нюансе.
Вмешаюсь.
1. Оно и не должно так работать как Вы хотите.
2. Если политикой безопасности дистрибутива определена невозможность чтения каталога /lib/modules простым пользователем, значит такое решение было оправдано. Вы считаете, что вправе поспорить с инженерами по безопасности компании ALT Linux? Извольте, но не в этой ветке.
3. Вам было предложено решение, использовать su -  для решения поставленной задачи.
Дело не в том как болезнь вылечить.
Дело в том как других заразить.

Оффлайн cobold

  • Начинающий
  • *
  • Сообщений: 9
Вмешаюсь.
1. Оно и не должно так работать как Вы хотите.
2. Если политикой безопасности дистрибутива определена невозможность чтения каталога /lib/modules простым пользователем, значит такое решение было оправдано. Вы считаете, что вправе поспорить с инженерами по безопасности компании ALT Linux? Извольте, но не в этой ветке.
3. Вам было предложено решение, использовать su -  для решения поставленной задачи.

Ок, пусть не должно работать автодополнение потому, что непривелигированному пользователю не следует знать список доступных модулей.
Но должно ли по нажатию TAB появляться сообщение об ошибке "ls: невозможно получить доступ к /lib/modules/2.6.25-std-def-alt8.M41.1: Отказано в доступе"?

Оффлайн Vitls

  • Глобальный модератор
  • *****
  • Сообщений: 372
  • Идиотизм вечен!
    • Linux. OpenSource. Life.
    • Email
Ок, пусть не должно работать автодополнение потому, что непривелигированному пользователю не следует знать список доступных модулей.
Но должно ли по нажатию TAB появляться сообщение об ошибке "ls: невозможно получить доступ к /lib/modules/2.6.25-std-def-alt8.M41.1: Отказано в доступе"?
А как иначе-то? По-другому оно и не сработает. Раз нет прав - значит нет прав.
Дело не в том как болезнь вылечить.
Дело в том как других заразить.

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
На своих домашних тазиках, где безопасность не важна - делайте chmod a+rx /lib/modules от рута, а дальше кувыркайтесь в свое удовольствие.

Открытый на чтение /lib/modules позволяет производить атаки типа DoS, когда локальный пользователь сможет, установив блокировку на файлы модулей, препятствовать таким образом операциям с этими модулями.
Ceterum censeo LORum esse delendam

Оффлайн cobold

  • Начинающий
  • *
  • Сообщений: 9
А как иначе-то? По-другому оно и не сработает. Раз нет прав - значит нет прав.

Да вот выше предлагался такой вариант:
А вообще раз позиция разработчиков в том, что читать юзеру /lib/modules небезопасно и список установленных модулей ядра больше взять не откуда, то может дописать  что-нибудь типа
if [ -r "$modpath" ]; then ...в скрипт bash_completion?

т.е, если текущий пользователь может прочесть директорию с модулями, дополнение сработает. А если прав нет, то и пусть автодополнение не сработает, но и бросаться ошибками имхо не нужно.

На своих домашних тазиках, где безопасность не важна - делайте chmod a+rx /lib/modules от рута, а дальше кувыркайтесь в свое удовольствие.

Открытый на чтение /lib/modules позволяет производить атаки типа DoS, когда локальный пользователь сможет, установив блокировку на файлы модулей, препятствовать таким образом операциям с этими модулями.

О как. Подкиньте пожалуйста название этого типа атаки(я не про DoS, а про блокировку модулей) или ключевые слова для гугления? Чисто в целях самообразования.

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
Названия этой атаки не знаю, и ключевых слов тоже.

Но в исходниках module-init-tools вижу следующие строчки

Цитировать
modprobe.c:

static int lock_file(const char *filename)
{
        int fd = open(filename, O_RDWR, 0);

        if (fd >= 0) {
                struct flock lock;
                lock.l_type = F_WRLCK;
                lock.l_whence = SEEK_SET;
                lock.l_start = 0;
                lock.l_len = 1;
                fcntl(fd, F_SETLKW, &lock);
        } else
                /* Read-only filesystem?  There goes locking... */
                fd = open(filename, O_RDONLY, 0);
        return fd;
}

И эта функция вызывается перед загрузкой модуля в память (и перед удалением тоже).
Как видно, запрашивается лок на запись. Если пользователь сделает лок на чтение на файл с модулем - то modprobe или rmmod будут вечно висеть, ожидая когда файл разблокируется.

Вот, сами проверьте:

Цитировать
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

int main(const int argc, const char** argv)
{
        int fd;
        struct flock lock;
        if (argc < 2)
        {
                fprintf(stderr, "usage: %s <filename>\n", argv[0]);
                return 1;
        }

        if ((fd = open(argv[1], O_RDONLY)) == -1)
        {
                perror("open");
                return 1;
        }
        lock.l_type = F_RDLCK;
        lock.l_whence = SEEK_SET;
        lock.l_start = 0;
        lock.l_len = 1;
        fcntl(fd, F_SETLKW, &lock);
        printf("Lock acquired\n. Press Ctrl-C to unlock.");
        sleep(-1);
        close(fd);
        return 0;
}
Сохраните эту программу в mod_dos.c. После чего скомпилируйте командой
gcc mod_dos.c -o mod_dos.

Далее открываете свой /lib/modules на чтение (chmod 755 /lib/modules от рута).

Далее выполняете команду ./mod_dos /lib/modules/`uname -r`/kernel/fs/ext2/ext2.ko от пользователя.
Оно должно вывести "Lock acquired. Press Ctrl-C to unlock".

Потом открываете сеанс рута и пишете там modprobe ext2. Наблюдаете зависон.

Делаете выводы, и выполняете команду chmod 700 /lib/modules.

После чего жмете Ctrl-C в окне с modprobe, потом в окне с DoS-эксплоитом.
Далее пробуете запустить эксплоит второй раз.
Должно вывести:

Цитировать
open: Permission denied

И соответственно, команда modprobe ext2 должна отрабатываться на ура.
Ceterum censeo LORum esse delendam

Оффлайн astroill

  • Завсегдатай
  • *
  • Сообщений: 51
  • Астрономия и Линукс!
    • Кубанский Астроклуб 45
    • Email
Надеюсь этот баг уже в багзиле kernel?
Пойду поищу, может в новых версиях ядрах уже пофиксили.
Т.к. chmod 700 не решение, а костыль.
Все, что я пишу - ИМХО и может не совпадать с реальностью.

Оффлайн wRAR

  • Завсегдатай
  • *
  • Сообщений: 469
Надеюсь этот баг уже в багзиле kernel?
Вы готовы спорить с авторами module-init-tools, что из их кода баг, а что фича?

А сообщение про неподумавши вы правильно удалили, да..

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
Это не баг, это фича. Локи требуются чтобы избежать race condition при загрузке модулей.

И chmod 700 /lib/modules - это правильное, кошерное решение, закрывающее целый класс атак.

Кстати, ядро тут вообще никак не влияет. Это не ядерный эксплоит.

Ваша квалификация в области компьютерной безопасности, к сожалению, пока оставляет желать лучшего.
« Последнее редактирование: 16.10.2008 14:38:47 от Damir »
Ceterum censeo LORum esse delendam

Оффлайн astroill

  • Завсегдатай
  • *
  • Сообщений: 51
  • Астрономия и Линукс!
    • Кубанский Астроклуб 45
    • Email
Надеюсь этот баг уже в багзиле kernel?
Вы готовы спорить с авторами module-init-tools, что из их кода баг, а что фича?
А что? Может эти авторы более открыты критике чем некоторые.  ;)
Ваша квалификация в области компьютерной безопасности, к сожалению, пока оставляет желать лучшего.
Наверно. Потому и пытаюсь опираться на мнение более компетентных.
Иногда это получается сделать очень сложно, когда у меня оказывается свое мнение.
Ну да ладно. Мне лично главное, чтобы родилась истина.
Все, что я пишу - ИМХО и может не совпадать с реальностью.

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
На мой взгляд тут истина простая - пока не опубликуешь эксплоит, все уверения команды безопасности ALT Linux, что /lib/modules закрыт для вашей же безопасности - просто игнорируются. Пока гром не грянет - мужик не перекрестится.

Будут ходить и нудить - ну дайте нам доступ, ну что вам жалко чтоли? Безопасность никому не нужна, главное, чтобы bash-completion работал от пользователя. Как будто эти ограничения Альт специально придумал, чтобы пользователям bash-completion насолить.
Ceterum censeo LORum esse delendam

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
Кстати, bash-completion как раз можно запатчить, чтобы он не по реальной файловой системе дополнял, а по результатам rpm -ql на пакет с ядром. Но тут надо хитрую систему соответствия городить, если ядер несколько в системе установлено.
Ceterum censeo LORum esse delendam