The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"В OpenBSD предложен новый системный вызов unveil() для изоля..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от opennews (?), 29-Июл-18, 09:04 
Тео де Раадт (Theo de Raadt) представил (https://marc.info/?l=openbsd-tech&m=153262228632102&w=2) патч с реализацией дополнительной защиты при помощи нового системного вызова unveil() (https://man.openbsd.org/unveil.2), который дополняет механизм ограничения доступа к системным вызовам pledge() (https://www.opennet.ru/opennews/art.shtml?num=43295). Новый системный вызов планируют включить в состав выпуска OpenBSD 6.4. В настоящее время код для защиты при помощи unveil() добавлен в 37 приложений из базовой системы OpenBSD, активировать патч планируется когда число приложений будет доведено до 50.


Системный вызов unveil() предоставляет новый способ изоляции доступа к файловой системе, интегрируемый в код приложений. Суть защиты заключается в том, что первым вызовом unveil() для приложения полностью блокируется доступ ко всей ФС. После чего выборочно открывается возможность доступа для отдельных путей, с которыми может работать приложение (реализация "белого списка" - по умолчанию всё запрещено, а необходимые пути следует явно разрешить).

Поддерживаются флаги ограничения доступа, т.е. можно отдельно открыть доступ на чтение, запись и исполнение, можно запретить создание или удаление файлов. Например, можно открыть доступ на запись к /tmp, на запуск /bin/sh и на чтение  /var/spool. Блокировка осуществляется через интеграцию дополнительных фильтров, работающих на уровне системных вызовов, связанных с файловыми операциями (open(), chmod(), rename() и т.п.).


URL: http://undeadly.org/cgi?action=article;sid=20180728063716
Новость: https://www.opennet.ru/opennews/art.shtml?num=49042

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +7 +/
Сообщение от Аноняшка (?), 29-Июл-18, 09:04 
А если открыт допуск  на запуск /bin/sh , - что еще надо подлому коту Леопольду? ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (4), 29-Июл-18, 09:15 
Как и sudo на запуск любого контекста
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –1 +/
Сообщение от Catwoolfii (ok), 29-Июл-18, 09:31 
Можно и не любого. Как настроишь, так и будет.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

28. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (28), 29-Июл-18, 18:28 
> Как и sudo на запуск любого контекста
> OpenBSD
> sudo

ну-ну.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (10), 29-Июл-18, 11:53 
В принципе,  в сочетании с pledge можно как раз очень сильно ограничить возможности запускаемого шелла. Но пример, действительно, не самый удачный.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

59. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (59), 31-Июл-18, 00:59 
Сам по себе /bin/sh не много умеет.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

62. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +3 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 31-Июл-18, 13:21 
> Сам по себе /bin/sh не много умеет.

Всего лишь запускать произвольные программы и открывать произвольные файлы, угу.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

2. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –4 +/
Сообщение от Аноним (4), 29-Июл-18, 09:06 
AppArmor в бинарнике сотворили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (24), 29-Июл-18, 16:30 
Тоже такая мысль сразу возникла.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +4 +/
Сообщение от Аноним (3), 29-Июл-18, 09:15 
Странно ограничивать приложение из него самого. Еще и окажется, что надо исходники править и пересобрать программу, чтобы добавить доступ в нужное тебе место, которое не предусмотрели разработчики.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –5 +/
Сообщение от Аноним (4), 29-Июл-18, 09:35 
Разработчикам стоит просто выпилить поддержку OpenBSD для решения проблемы.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

19. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +4 +/
Сообщение от Аноним (28), 29-Июл-18, 12:53 
> Разработчикам стоит просто выпилить поддержку OpenBSD для решения проблемы.

Разработчикам чего? Решению какой именно проблемы?

Боюсь, выпиливание поддержки опенка (т.е. на самом деле сознательное прибивание гвоздями к линуксизмам) не сможет заставить Экспертов Опеннета читать перед тем как комментировать и давать мудрые советы.


Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от anonymous (??), 29-Июл-18, 11:02 
Наоборот, только приложение (автор приложения) знает какие доступы ему нужны. А пытаться угадывать через selinux/apparmor это как суслика в поле искать — можно, но нужно с ведерком по норам побегать.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Prototik (ok), 29-Июл-18, 11:33 
Ну да, и автор тоже великолепно знает, куда я хочу положить данные.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

13. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от anonymous (??), 29-Июл-18, 12:07 
> Ну да, и автор тоже великолепно знает, куда я хочу положить данные.

А что, у нас open уже мысли научился читать? Так или иначе белый путь приложение будет знать.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –1 +/
Сообщение от Аноним (20), 29-Июл-18, 15:12 
>Так или иначе белый путь приложение будет знать.

C:\Program Files\Program name\Temp

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

21. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от anonymous (??), 29-Июл-18, 15:17 
Я могу тоже написать любой путь. Какая мысль скрыта за ним? То что на системе пользователя C:\Program Files может быть любым? Ну так приложение как-то же делает open('Temp'). Считает от cwd или еще как узнает путь до установки. В общем автор и приложение все знают, не переживайте.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

11. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (10), 29-Июл-18, 11:58 
Более того, именно само приложение знает, когда привилегии перестают быть нужны. Скажем, тот же web-сервер нуждается в повышенных привилегиях и доступе к произвольным каталогам обычно только на этапе инициализации, а дальше список рабочих каталогов известен, сокеты все открыты - знай, принимай подключения, отдавай страницы.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +8 +/
Сообщение от Аноним (14), 29-Июл-18, 12:23 
> Наоборот, только приложение (автор приложения) знает какие доступы ему нужны

Я автор софта для наложения смешных эффектов на фотки. Моему приложению нужен доступ к камере, микрофону, галерее, списку контактов и истории браузера

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +2 +/
Сообщение от anonymous (??), 29-Июл-18, 12:31 
> Я автор софта для наложения смешных эффектов на фотки.

Вам лучше так и оставаться на прикладном уровне и пользоваться android sdk. Ограничения по сисколам пока не для вас.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

27. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +6 +/
Сообщение от .. (?), 29-Июл-18, 18:17 
man sarcasm
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –2 +/
Сообщение от aknor (?), 29-Июл-18, 12:33 
Очевидное применение , - ограничивать любой интерпретатор  ...
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

17. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +2 +/
Сообщение от Аноним (28), 29-Июл-18, 12:39 
> Странно ограничивать приложение из него самого.

Странно не слышать ни разу о "добровольном" сбросе привилегий на случай уязвимостей.
https://www.google.ru/search?q="drop+privileges"

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

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

45. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (45), 30-Июл-18, 00:54 
Чувак, я ничерта не понял из того что ты сказал, но ты заговорил и достучался до моего сердца.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

31. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (31), 29-Июл-18, 19:57 
Если приложение может прочитать путь из конфига, оно его и будет вайтлистить, не?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

35. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +5 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 20:47 
unveil — это защита от ситуаций, когда порядочная программа взламывается и кто нехороший с её помощью начинает делать то, что эта программа делать не должна. Если вам нужна защита от запуска изначально вредоносного кода, то вам к Данилову и прочим.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Alexemail (??), 29-Июл-18, 11:21 
Это аналог firejail
OpenBSD +1
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (10), 29-Июл-18, 12:00 
Нет, это не аналог firejail. Приезжайте на LVEE, расскажу подробнее. ;)
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

50. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +3 +/
Сообщение от Аноним (50), 30-Июл-18, 03:43 
firejail (и используемый там seccomp) на бумаге гибче, но на практике абсолютно убоги

Об проблемах с seccomp можно писать до бесконечности. Если вкратце...

Режим чёрного списка бесполезен: автор приложения запретит open() и stat(), а через пару релизов ядра выкатят какие-нибудь openat() и fstatat(), которые делают то же самое, но уже не блокируется фильтром. Упс...

Отдельные списки доступа для разных ABI. Если заранее не RTFM, можно легко оказаться в положении, когда твой sandbox обходится использованием версии того же системного вызова, но для 32-битной архитектуры. При этом у 32-битной и 64-битной архитектур могут сильно отличаться списки сисколов, — см. socket()

В теории, с seccomp можно делать очень много чего, — например разрешать доступ к отдельным путям. На практике, ­— если у системного вызова несколько вариантов (это к слову про stat, fstat, newstat, fstatat и т.д.), то придётся писать отдельные фильтры для каждого варианта. Из-за этого никто не заморачивается со сложными фильтрами.

Создание _работающего_ белого списка seccomp — практически нереальная задача, если ты не разработчик своей ОС, и не линкуешь всё приложение статически (включая libc). PAM, NSS, поддержка локалей в glibc и и даже банальная ленивая загрузка библиотек через dlopen() ставят firejail раком, — белый список быстро разрастается до 100% поддерживаемых ядром системных вызовов. Хочешь слинковать с  libpng.so? Разрешай в конфиге весь набор вызовов для работы с ФС. В новой версии glibc добавили новую фичу, требующую чтения нового файла конфига? Весь твой sandbox накрывается медным тазом с очередным апдейтом системы.

Фактически, разработчики ядра Linux свалили весь груз проблем по написанию seccomp-правил на головы прикладных программистов. В его текущем виде seccomp годится только для изоляции процесса javascript-интерпретатора (и то — с очень большим списком оговорок). По сравнению с ним, unveil() — просто мечта.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

18. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (18), 29-Июл-18, 12:42 
Я в начале подумал, что системный вызов назвали unevil
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 15:24 
Это обыгрывалось, да, только уже не помню, кем. :))
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –2 +/
Сообщение от Аноним (23), 29-Июл-18, 16:06 
когда хотели изобрести SELinux, но не догадались вынести список файлов в отдельный конфиг, чтобы не патчить весь софт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (28), 29-Июл-18, 17:02 
> когда хотели изобрести SELinux, но не догадались вынести список файлов в отдельный
> конфиг, чтобы не патчить весь софт.

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от anonymous (??), 29-Июл-18, 18:00 
Когда кто-то хотел сумничать, но громко напузырял. Пути сцеплены с логикой приложения. И разделять их можно только от безисходности (это база проектирования любой системы), собственно selinux и реализует костыльный вариант.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

29. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –4 +/
Сообщение от Аноним (29), 29-Июл-18, 19:27 
Что в SELinux костыльного? Реализация в ядре, гибкая настройка всего и всея в юзерспайсе. Опенбздишнекам стоило бы поучиться, а не дрчить протезной лапой, как обезьяна в "Кремниевой долине"
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

30. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от adaww (?), 29-Июл-18, 19:45 
чувааак ! тут недавно нет бсд 8 вышла...;) с тем же pkgsrc...не нравится опенка ибашЪ юзай ее или фрю. и не иби мозги...
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

32. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +5 +/
Сообщение от Аноним (31), 29-Июл-18, 20:38 
Все. Потому что написание правил selinux заслуженно считается крайне трудоемким занятием, требующим сотни человекочасов для тестирования всех случаев.

А это скорее аналог sandboxing, как в chrome и firefox.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

36. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 20:54 
Верно. Как раз для Chrome уже давно реализована песочница на базе pledge(), теперь к ней добавляется и unveil. Для unveil() ещё нужна доработка, но в целом уже работает. С Firefox, к сожалению, всё не так хорошо, но уже есть пара патчей, добавляющих поддержку pledge(), а там и до unveil() недалеко.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

37. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (31), 29-Июл-18, 20:55 
В лялихе не через pledge, там seccomp.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 21:07 
Угу. К SECCOMP ещё несколько лет назад была масса вопросов (вроде возможности отыграть назад, фактически, выключая seccomp), сейчас — может, под давлением pledge? — часть из них решилась.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

40. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (31), 29-Июл-18, 21:28 
Насчет отыграть не в курсе — можно ссылку?
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

46. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 01:29 
PR_SET_NO_NEW_PRIVS появился в 3.5 только, если я правильно разобрался.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

60. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от A. Stahl Is Gay (?), 31-Июл-18, 13:04 
Если я правильно понял описание, то это для того, чтобы потомки не могли делать то, что не может делать родитель.
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

63. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 31-Июл-18, 13:25 
> Если я правильно понял описание, то это для того, чтобы потомки не
> могли делать то, что не может делать родитель.

И это тоже, так как в seccomp, насколько помню, привилегии просто наследуются. В pledge же можно явно задать привилегии именно для exec'нутых процессов. Если ошибаюсь, прошу поправить. :)

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

34. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 20:43 
В OpenBSD механизмы ограничения системных вызовов были тогда, когда на Linux не было вообще ничего подобного. Это уже далеко не первое поколение.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

65. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (65), 05-Авг-18, 23:50 
RSBAC, позволяющий ограничить все что угодно в линухе, появился в 2000 году. В то время опенок еще даже не был в состоянии загрузится на реальном железе(впрочем и сейчас с железом которому менее 10 лет у опенка жесткие проблемы).
А ты продолжай врать.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

66. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 06-Авг-18, 02:22 
1. «Появился» он в виде патча, а не в mainline ядре. Напомните, когда он стал частью дефолтного ядра в каком-либо крупном дистрибутиве? Потому что сравнивать доступный где-то патч и изначально доступную и работающую функциональность как-то некорректно, не находите?

Впрочем, я уже поправился по соседству, говоря про SELinux, — надо было здесь тоже, признаю.

2. OpenBSD работал на реальном железе и куче архитектур с момента рождения. В отличие от изначально x86-only Linux (я очень рад за ядро Linux, что сейчас оно может куда больше, чем в 1995-м). «А ты продолжай врать».

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

42. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –1 +/
Сообщение от Аноним (42), 29-Июл-18, 22:48 
Я сам линуксоид, но SELinux - переусложненная хрeнь, которая, мягко говоря, не украшает стек. Костыльного в ней то, что профили по умолчанию долго пилились методом проб и ошибок в стиле "Запускаем нечто, оно вылетает. Ого, оно оказывается еще и такой доступ требует? Даем!" Это позорище! Профиль безопасности должен быть частью самого приложения, авторы лучше знают, что приложению надо. Так что даешь unveil(), но только более мощный.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

44. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Аноним (44), 30-Июл-18, 00:24 
Не знают и не могут знать.

man pam
man nss

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

47. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 01:32 
А это как раз много «хорошего» говорит об архитектуре PAM и NSS.

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

55. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Crazy Alex (ok), 30-Июл-18, 19:15 
Вообще-то это называется "API" и "information hiding". Приложение должно знать то, что оно само делает. Как именно работают используемые им сервисы, оно знать и не должно. В том числе и куда они лезут - это уровень системы.
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

57. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 19:42 
> Вообще-то это называется "API" и "information hiding". Приложение должно знать то, что
> оно само делает. Как именно работают используемые им сервисы, оно знать
> и не должно. В том числе и куда они лезут -
> это уровень системы.

Это было бы information hiding, если бы таковые форки, открытие файловых дескрипторов и прочая, и прочая не влияли бы на работу приложения. Но ведь они влияют! В любой момент, получается, могут оказаться открыты только что закрытые файловые дескрипторы; обработчик сигнала может оказаться затёрт, или наоборот, оказаться вызванным в неожиданном окружении; состояние глобальной переменной может измениться; неожиданно окажется взятой какая-то блокировка (ручкой машет дед Лок), и ещё много вызывающих сбои ситуаций.

Позиция «если вы вызовете эту функцию, то может произойти всё, что угодно, а если не вызовете — тем более, ваше приложение не может ни на что рассчитывать» удобна только для того, кто такое API реализует, но не для разработчика приложения, который не может более гарантировать пользователю корректную работу своей программы при одних и тех же настройках программы и под одной и той же ОС. Как следствие, головная боль появляется у пользователя/админа, что как бы противоречит исходной задаче, решаемой ИТ — делать пользователям хорошо.

Так что далеко не всякая абстракция является качественной, увы.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

49. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (50), 30-Июл-18, 03:00 
Ты бы ещё LD_PRELOAD вспомнил
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

53. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от КО (?), 30-Июл-18, 10:16 
>Реализация в ядре, гибкая настройка всего и всея в юзерспайсе.

И маленький ньюанс.
Для ускорения всего и вся занесли чать Самбы в ядро (ну чтоб меньше переключений контекста).
Все тру... И тут Селинукс начал вопить - куски йадра утекают всеть - запретить. Правда и сам не мог объяснить толком что именно и ссылался на забавные имена файлов в корневой системе. Завели баг, все пучком.
- разработчи селунукса : надо чтоб пакеты помечались пусть сделают
- самбисты : это к ядерщикам, они их генерят
- ядерщики : это не к нам, мы такой фигней не маемся - пишите правила
- писатели правил : это что? нам писать правило можно все из ядра в сеть? а зачем тогда все? Самбисты - метьте пакет.
- самбисты : да сказано же, мопед ядерщиков
- ядерщики : мопед не наш, мы только объяву разместили, пишите правила...

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

51. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Orduemail (ok), 30-Июл-18, 04:11 
> собственно selinux и реализует костыльный вариант.

SELinux -- это не костыльный вариант. Это классический корпоративный оверинжиниринг.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

56. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Crazy Alex (ok), 30-Июл-18, 19:17 
Который при этом так же классчиески работает в корпоративных системах, не привязан к заморочкам самого приложения и допускает отдельный аудит правил. А вот как сделать аудит того, что предлагают в топике, без аудита всего кода приложения - не представляю.
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

58. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +2 +/
Сообщение от Orduemail (ok), 30-Июл-18, 22:04 
> Который при этом так же классчиески работает в корпоративных системах, не привязан
> к заморочкам самого приложения и допускает отдельный аудит правил.

Да-да, я о том же. Корпоративный оверинжиниринг, попытка решить 200% проблем одним комбайном. В частности проблему запуска недоверенным пользователем недоверенного кода, которому нужны рутовские привилегии для вызова какого-то там сисколла. Мне ближе решения, которые решают 90% проблем, но при этом не впадают в переусложнённость. Проблема с этими 200% в том, что из них 150% как минимум меня вообще не касаются, а вот сложность которая идёт рука об руку с двухсотпроцентными решениями никуда не девается, она тут. У меня нет недоверенных пользователей, а недоверенный код я всё равно запускаю в виртуалке -- SELinux или не SELinux, виртуалка проще. Поэтому у меня система собрана без поддержки SELinux'а. Но вот от pledge с unveil я бы не отказался.

Я не корпорация, у меня нет переизбытка инженерных мощностей для того, чтобы справляться с ненужными мне переусложнениями. Поэтому pledge и unveil выглядят для меня очень вкусно, а SELinux выглядит бесформенным куском оверинжиниринга, к которому я близко не подойду. И, собственно, почитав маны на pledge и unveil, я внезапно перестал понимать, что я вообще забыл в linux'е. Чтение этих манов вызвало во мне чувство, которое я испытывал 15 лет назад, когда впервые оказался в linux'е после венды и читал маны к libc.so. Чувство, которое можно выразить словами "неужели можно так просто?". Тогда из-за этого чувства я отказался от венды насовсем. Сейчас... Сейчас это лишь ностальгия, без каких-либо последствий -- не знаю куда валить отсюда... видимо старый я стал, пора завязывать с технологиями и заниматься огородом.

А, да. Все эти корпоративные плюшки и их "полезность" для не-корпорации, напомнила мне текст, который я тут намедни читал, он разбирает этот вопрос на примере применимости Java или PHP для стартапа[1]. Оставь корпоративное корпорациям. Пускай они сами занимаются написанием и аудитом политик SELinux'а для твоих программ, это их личные половые трудности. А вот использовать pledge/unveil в своей программе может быть полезным уже потому, что заставит тебя подумать о том, какие привилегии ей нужны и на каком этапе её выполнения, и может быть даже они приведут к тому, что ты несколько перелопатишь код, с тем чтобы была возможность отнять у main-loop'а вообще все привилегии, оставив ему лишь несколько заранее открытых файловых дескрипторов. Но даже если ты лишь подумаешь об этом, то это положительным образом скажется на безопасности твоей программы, даже если она будет работать в linux'е, где нет ни pledge, ни unveil. А вот SELinux не сделает твою программу лучше, он лишь усложнит систему, в которой твоя программа работает.

[1] https://medium.com/@alexkatrompas/java-will-kill-your-s...

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

33. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  –1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 20:41 
1. SELinux появился куда позднее, скажем, systrace — который в OpenBSD уже давно успели выпилить.

2. SELinux не позволяет изменить привилегии после инициализации приложения, то есть программа всегда работает с максимально допустимыми привилегиями.

3. SELinux куда сложнее, в плохом смысле этого слова, и заточен прежде всего под соответствие требованиям законодательства (США), а не реальные потребности.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

39. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 21:21 
... и тут я немного наврал:
хотя systrace был добавлен в OpenBSD в 2002 году, а SELinux в ядро — в 2003-м, но именно презентован SELinux в виде, доступном для использования, был всё же раньше, в 2000-м.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

41. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от Orduemail (ok), 29-Июл-18, 22:24 
А ограничения наследуются дочерними процессами?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от антончик (?), 30-Июл-18, 00:13 
Тоже задался таким вопросом. Можно было бы написать шелл-враппер для старта программы и явно указать куда ей можно ходить, чтоб в ~/.ssh даже не думала заглядывать.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

52. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Аноним (52), 30-Июл-18, 06:48 
Получается с unveil нужно еще системное приложение писать, для программ которые его пока не поддерживают. Типо файрволла, только с правилами путей?
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

54. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 13:07 
Написать можно, но смысл теряется: немалая часть путей при типовом использовании pledge/unveil актуальна только на этапе инициализации, а при использовании внешнего приложения получается, что мы всегда позволяем максимум требуемого всегда.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

48. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 01:36 
Для pledge это определяется вторым аргументом, он позволяет задать ограничения именно для запускаемых через exec бинарников. Для unveil семантика ещё до конца не устаканилась, что-то может поменяться, — изначально эта функциональность вообще планировалась как часть pledge, но постепенно стало понятно, что нужен другой принцип работы, поэтому и системный вызов отдельный.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

61. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Урри (?), 31-Июл-18, 13:14 
подпишусь ка я...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "В OpenBSD предложен новый системный вызов unveil() для изоля..."  +/
Сообщение от Daemon (??), 01-Авг-18, 23:25 
Тео видимо на тяжелые наркотики с пива перешел ))))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру