LINUX.ORG.RU

kernel-3.7.6 CAP_SYS_RAWIO на /dev/cpu/*/msr


0

1

В 3.7.6. «подарок» от Алана Кокса в msr_open:

if (!capable(CAP_SYS_RAWIO))
        return -EPERM;

а у меня питоно-скрипт, который эти самые model-specific register читает от юзера.

Сделал:

# setcap cap_sys_rawio+ep /path_to_script/script.py
всё-равно, нифига не читает скрипт регистры.

Я в этих capabilities не очень, может что упускаю?

★★★★★

Братюнь, на /usr/bin/python должно стоять cap_sys_rawio, домашнее задание тебе подумать почему.

anonymous
()
Ответ на: комментарий от anonymous

Dude, не угадал ты.

# ls -l /usr/bin/python
lrwxrwxrwx 1 root root 14 марта 23  2012 /usr/bin/python -> python-wrapper

Пробовал я повышать привилегии и python-wrapper и /bin/env, и даже /usr/bin/python2.7, но нет, под юзером OSError: [Errno 13] Отказано в доступе: '/dev/cpu/0/msr'.

Что из школьной программы я пропустил?

vvn_black ★★★★★
() автор топика
Ответ на: комментарий от vvn_black

даже /usr/bin/python2.7

Дак только их и надо было повышать, при условии, что python-wrapper запускает именно версию 2.7, а, не, допустим, /usr/bin/python3.1.

Вобще схема с setcap на /usb/bin/pythonX рабочая: iotop и capabilities , попробуйте в своём скрипте в начале указать именно /usr/bin/python2.7 и проверить.

mky ★★★★★
()
Ответ на: комментарий от mky

Дак только их и надо было повышать

Ваша правда, с #!/usr/bin/python2.7 в скрипте всё заработало. Спасибо. Но, блин, как же это всё.... не очень по-людски.

http://packages.python.org/python-prctl/

Интересная штука, раньше не видел, спасибо, посомтрю.

vvn_black ★★★★★
() автор топика
Ответ на: комментарий от vvn_black

Но, блин, как же это всё.... не очень по-людски.

Да, разработчики ядра ненавидят скрипты и всячески их притясняют, и suid на них не работает, и setcap не работает :-)

Если серьёзно, то ставить capabilities ″+ep″ на /usr/bin/python2.7 не безопастно (все скрипты на питоне получат эту возможность и не надёжно. Ставить на интерпретатор только ″+i″ и писать «запускалку» на Си, как в приведённой мною ссылке, просто ненадёжно. Под ненадёжностью я подразумеваю, что при обновлнии питона бинарник интерпретатора будет перезаписан и capabilities обнулятся.

Попробуйте ковырнуть выполнение вашего скрипта не через «ше-банг», а через /proc/sys/fs/binfmt_misc. Вот здесь http://www.kernel.org/doc/Documentation/binfmt_misc.txt написано, что можно указать флаг 'C' и тогда при выполнении файла этого типа его ″credentials and security token″ будут вычислятся по файлу, а не по интерпретатору.

Дайте вашему скрипту права через setcap и расширение .python, допустим, уберите превую строку с ″#!″ и создайте запись в /proc/sys/fs/binfmt_misc/register. Не знаю, работает ли это или нет, мне самому проверять не охота, а узнать интерестно :-)

Прописывать тудат надо /usr/bin/python2.7, а не /usr/bin/python, так как python-wraper делат exec() и теряет установленные capabilities. Хотя, может я путаюсь.

mky ★★★★★
()
Ответ на: комментарий от mky

Будет чем заняться на выходных. )

Видел информацию от эмбедщиков про msr_whitelist в ядре, кмк, безопасность безопасностью, но ставить такие ограничения на чтение всех регистров - это и правда слишком.

vvn_black ★★★★★
() автор топика
Ответ на: комментарий от mky

Не знаю, работает ли это или нет, мне самому проверять не охота, а узнать интерестно

Всё заняло времени много меньше, чем я думал. Оно работает! И по расширению и по сигнатуре. С 'С' ″credentials and security token″ действительно считаются от файла скрипта.

vvn_black ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.