LINUX.ORG.RU

в чем смысл запрета исполнения?

 ,


0

1

нубский вопрос, да. Что то я не понимаю, если злоумышленник может выполнить код, то как ему должен помешать запрет на исполнение сделать бяку? скажем, создает он файл wrong.readonlyfile потом пишет somelang wrong.readonlyfile. Ну, как бы, очевидная вещь. Если тут это не спасает, то где тогда?



Последнее исправление: filequest (всего исправлений: 1)

Если suid не учитывать, то почти декоративный. Ты же своим файлам можешь любой mode задать.

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

Как ничтожно? Скрипт всегда можно прочитать и если там обфускация, то смело посылать на %$&. Бинарник же всегда какая-то НЕХ.

ados ★★★★★
()

46 лет назад, вероятно, не думали о том, как будут себя вести шеллы в 2016.

В случае бинарных исполняемых файлов, устанавливаемых в систему, это «спасает».

Думаю, тогда, когда придумали execution permission bit, он хорошо подходил под тогдашние use cases (интересно было бы разобраться в истории его появления). Сейчас, согласен, он не всегда так полезен. Поменялись системы, появились более сложные средства контроля доступа - ACL, LSM.

Andrey_Utkin ★★
()

Ещё не стоит забывать, что снятие флага исполнения на каталогах не пустит внутрь, что довольно-таки нужно.

Bfgeshka ★★★★★
()

Право выполнения (x) служит скорее для предотвращения нечаянного выполнения не пойми чего и для отличения исполняемых файлов от всех прочих. Кроме того, оно служит для скрытия содержимого каталогов.

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

глупо как-то это все. Если боишься случайно запустить файл, просто убери его подальше с глаз. Если хочешь скрыть каталог — перенеси его туда, где он будет недоступен.

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

Если боишься случайно запустить файл, просто убери его подальше с глаз.

А что же, все файлы, с которыми ты работаешь, предназначены для исполнения?

Если хочешь скрыть каталог — перенеси его туда, где он будет недоступен.

В смысле? Без права исполнения на каталоге другие пользователи не смогут прочитать список файлов в нём.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от Esteban_Garcia

Внутри всё равно права тоже выставляются, а так не узнать содержимое.

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

Кстати, в убунте (или даже в Gnome?) флаг «x» использован довольно «своеобразно»: при запуске файла из ФМ и отсутствии данного флага появляется окошко с сообщением «файлы из Интернета могут повредить ваш компьютер» (или что-то подобное, не помню).

KennyMinigun ★★★★★
()
Ответ на: комментарий от ados
/lib64/ld-linux-x86-64.so.2 wrong.readonlyfile

и другие способы починить chmod -x chmod...

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

Если хочешь скрыть каталог — перенеси его туда, где он будет недоступен

да, перенеси хомяк

MyTrooName ★★★★★
()

Всё чуть не так как объясняют.

Есть простое правило ИТ безопасности - всё что исполняется не должно изменятся, а всё что изменяется не должно исполнятся.

Этого стараются добиться простыми и дешевыми методами. По этому не следует держать wx на диске и в памяти компа! Прописывают это как глобально опциями монтирования noexec & ro, патчами ядра GrSec&PAX, так и дешевыми методами типа TPM (доверительный путь исполнения файлов).

Можно использовать и дорогие методы MAC, RSBAC.

Далее простота и дешевизна безопасности, контролировать отсутствие wx спасает в 99% от детских вирусов.

Бинарники точно не запустятся. А через шел есть возможность запуска скриптов которые можно просмотреть.

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

Пробить подпись по доверенным CA

Так и сделали ДрВЕБ с Каспером, поверили действительной подписи от realtek и пропустили stuxnet. В результате из за доверия исполняемому файлу по подписи CA Иран лишился всех центрифуг и не смог создать ядерную бомбу!

В система должна на 100% состоять с лично собранных бинарей, которые собирались с проверенных, хотя бы по хешам исходников. Остальные бинари не должны иметь возможность запустится на проце!

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

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

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

Подпись хорошо справляется с эпидемиями, но не с одиночными атаками.

Цифровая подпись может успешно противостоять любым атакам при надлежащем использовании!

В выше приведённом примере есть злой умысел фирм JMicron и Realtek подписавших вирус своей цифровой подписью.

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

Но если, двое порядочных без третьих лиц напрямую, непосредственно, обменялись ключами, то магия криптографии гарантирует неизменность и аутентичность полученных программ.

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

Без права исполнения на каталоге другие пользователи не смогут прочитать список файлов в нём.

господи. нет. пять звезд, базовые вещи же:

yunake@x230:~/tmp/d1$ mkdir a
yunake@x230:~/tmp/d1$ touch a/m
yunake@x230:~/tmp/d1$ chmod -x a
yunake@x230:~/tmp/d1$ ls -ld a
drw-r--r-- 2 yunake wheel 4096 Apr  3 13:31 a
yunake@x230:~/tmp/d1$ ls -l a
/bin/ls: cannot access 'a/m': Permission denied
total 0
-????????? ? ? ? ?            ? m


т.е. список файлов получить можно. это управляется правом read а не x.

val-amart ★★★★★
()
Ответ на: комментарий от multihead

Но если, двое порядочных без третьих лиц напрямую...

Еще раз, что мешает спереть закрытый ключ у одного из них?

Я говорю о распределении вероятностей определенных событий. Когда есть поток программ из миллионов, и среди них есть вредоносные - не будут малварщики покупать каждый раз новый сертификат, ибо обанкротятся.

JN
()
Ответ на: комментарий от val-amart

т.е. список файлов получить можно. это управляется правом read а не x.

Тьфу! Я перепутал. x даёт возможность получать inode и открывать файлы в директории (ну и делать chdir).

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.