В настоящее время я обновляю исходный код Linux LSM (ядро 4.3.5), чтобы он был совместим с новейшей версией ядра Linux.
Я успешно обновил код, поэтому компилятор G CC успешно компилируется, однако ядро не загружается.
До этого момента я не использовал флаг LSM MAJOR или флаг EXCLUSIVE в определении модуля, однако при загрузке в нерабочее ядро выдаются ошибки SMACK и SE Linux (в зависимости от того, какое из них выбрано в качестве основного), и в трассировке упоминается kmem_cache_free. Насколько я понимаю, из-за этого мой LSM должен быть реализован как устаревший и эксклюзивный. Это потому, что SMACK или Se linux плохо играют с моим LSM, точно так же, как они не друг с другом? (Как примечание, SMACK и Se linux оба используют эксклюзивные и унаследованные основные флаги)
Разрабатываемый мной LSM использует xattrs для сохранения правил в inode, а LSM обеспечивает посредничество для inode на основе rules.
Во всей прочитанной документации всплывают двоичные объекты безопасности, теперь я понимаю, что они являются структурами данных ядра, и если я обращаюсь только к inode, мне не нужно реализовывать один из них. ?
LSM использует кеш ядра с kmem_cache_create(), что SE Linux также использовало в своей версии ядра 4.3.5, это блок безопасности?
Напомним: