forum.opennet.ru

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

Оглавление

В OpenBSD предложен новый системный вызов unveil() для изоля..., opennews (?), 29-Июл-18, (0) [смотреть все]

А если открыт допуск на запуск bin sh , - что еще надо подлому коту Леопольду , Аноняшка (?), 09:04 , 29-Июл-18, (1) +7 //

Как и sudo на запуск любого контекста, Аноним (4), 09:15 , 29-Июл-18, (4) –1 //

Можно и не любого Как настроишь, так и будет , Catwoolfii (ok), 09:31 , 29-Июл-18, (5) –1
ну-ну , Аноним (28), 18:28 , 29-Июл-18, (28) +1

В принципе, в сочетании с pledge можно как раз очень сильно ограничить возможно, Аноним (10), 11:53 , 29-Июл-18, (10)
Сам по себе bin sh не много умеет , Аноним (59), 00:59 , 31-Июл-18, (59) //

Всего лишь запускать произвольные программы и открывать произвольные файлы, угу , PereresusNeVlezaetBuggy (ok), 13:21 , 31-Июл-18, (62) +3

AppArmor в бинарнике сотворили , Аноним (4), 09:06 , 29-Июл-18, (2) –4 //

Тоже такая мысль сразу возникла , Аноним (24), 16:30 , 29-Июл-18, (24)

Странно ограничивать приложение из него самого Еще и окажется, что надо исходни, Аноним (3), 09:15 , 29-Июл-18, (3) +4 //

Разработчикам стоит просто выпилить поддержку OpenBSD для решения проблемы , Аноним (4), 09:35 , 29-Июл-18, (6) –5 //

Разработчикам чего Решению какой именно проблемы Боюсь, выпиливание поддержки , Аноним (28), 12:53 , 29-Июл-18, (19) +4
Леннарт, залогиньтесь , Аноним (67), 10:59 , 19-Ноя-19, (67)

Наоборот, только приложение автор приложения знает какие доступы ему нужны А , anonymous (??), 11:02 , 29-Июл-18, (7) +1 //

Ну да, и автор тоже великолепно знает, куда я хочу положить данные , Prototik (ok), 11:33 , 29-Июл-18, (9) +1 //

А что, у нас open уже мысли научился читать Так или иначе белый путь приложение, anonymous (??), 12:07 , 29-Июл-18, (13) +1

C Program Files Program name Temp, Аноним (20), 15:12 , 29-Июл-18, (20) –1

Я могу тоже написать любой путь Какая мысль скрыта за ним То что на системе по, anonymous (??), 15:17 , 29-Июл-18, (21) +1

Конечно знает Хардкоденные пути он и так знает Нехардкоденные - прочитает из к, Аноним (67), 11:01 , 19-Ноя-19, (68)

Более того, именно само приложение знает, когда привилегии перестают быть нужны , Аноним (10), 11:58 , 29-Июл-18, (11) +1
Я автор софта для наложения смешных эффектов на фотки Моему приложению нужен до, Аноним (14), 12:23 , 29-Июл-18, (14) +8 //

Вам лучше так и оставаться на прикладном уровне и пользоваться android sdk Огра, anonymous (??), 12:31 , 29-Июл-18, (15) +2

man sarcasm, .. (?), 18:17 , 29-Июл-18, (27) +7

GPS, биометрический сенсор и доступ к фитнес-трекеру забыл , Аноним (67), 11:02 , 19-Ноя-19, (69)

Очевидное применение , - ограничивать любой интерпретатор , aknor (?), 12:33 , 29-Июл-18, (16) –2
Странно не слышать ни разу о добровольном сбросе привилегий на случай уязвимос, Аноним (28), 12:39 , 29-Июл-18, (17) +2 //

Чувак, я ничерта не понял из того что ты сказал, но ты заговорил и достучался до, Аноним (45), 00:54 , 30-Июл-18, (45) +1

Если приложение может прочитать путь из конфига, оно его и будет вайтлистить, не, Аноним (31), 19:57 , 29-Июл-18, (31) +1
unveil 8212 это защита от ситуаций, когда порядочная программа взламывается и, PereresusNeVlezaetBuggy (ok), 20:47 , 29-Июл-18, (35) +5

Это аналог firejailOpenBSD 1, Alex (??), 11:21 , 29-Июл-18, (8) –1 //

Нет, это не аналог firejail Приезжайте на LVEE, расскажу подробнее , Аноним (10), 12:00 , 29-Июл-18, (12)
firejail и используемый там seccomp на бумаге гибче, но на практике абсолютно , Аноним (50), 03:43 , 30-Июл-18, (50) +3

Я в начале подумал, что системный вызов назвали unevil, Аноним (18), 12:42 , 29-Июл-18, (18) +1 //

Это обыгрывалось, да, только уже не помню, кем , PereresusNeVlezaetBuggy (ok), 15:24 , 29-Июл-18, (22) +2

когда хотели изобрести SELinux, но не догадались вынести список файлов в отдельн, Аноним (23), 16:06 , 29-Июл-18, (23) –2 //

Когда лапчато-перепончатые не в курсе, но гордо задранную гузку после высказыван, Аноним (28), 17:02 , 29-Июл-18, (25)
Когда кто-то хотел сумничать, но громко напузырял Пути сцеплены с логикой прило, anonymous (??), 18:00 , 29-Июл-18, (26) //

Что в SELinux костыльного Реализация в ядре, гибкая настройка всего и всея в юз, Аноним (29), 19:27 , 29-Июл-18, (29) –4 //

чувааак тут недавно нет бсд 8 вышла с тем же pkgsrc не нравится опенка , adaww (?), 19:45 , 29-Июл-18, (30) –1
Все Потому что написание правил selinux заслуженно считается крайне трудоемким , Аноним (31), 20:38 , 29-Июл-18, (32) +5

Верно Как раз для Chrome уже давно реализована песочница на базе pledge , тепе, PereresusNeVlezaetBuggy (ok), 20:54 , 29-Июл-18, (36)

В лялихе не через pledge, там seccomp , Аноним (31), 20:55 , 29-Июл-18, (37)

Угу К SECCOMP ещё несколько лет назад была масса вопросов вроде возможности от, PereresusNeVlezaetBuggy (ok), 21:07 , 29-Июл-18, (38)

Насчет отыграть не в курсе 8212 можно ссылку , Аноним (31), 21:28 , 29-Июл-18, (40) +1

PR_SET_NO_NEW_PRIVS появился в 3 5 только, если я правильно разобрался , PereresusNeVlezaetBuggy (ok), 01:29 , 30-Июл-18, (46)

Если я правильно понял описание, то это для того, чтобы потомки не могли делать , A. Stahl Is Gay (?), 13:04 , 31-Июл-18, (60)

И это тоже, так как в seccomp, насколько помню, привилегии просто наследуются В, PereresusNeVlezaetBuggy (ok), 13:25 , 31-Июл-18, (63)

В OpenBSD механизмы ограничения системных вызовов были тогда, когда на Linux не , PereresusNeVlezaetBuggy (ok), 20:43 , 29-Июл-18, (34)

RSBAC, позволяющий ограничить все что угодно в линухе, появился в 2000 году В т, Аноним (65), 23:50 , 05-Авг-18, (65) –1

1 171 Появился 187 он в виде патча, а не в mainline ядре Напомните, когда , PereresusNeVlezaetBuggy (ok), 02:22 , 06-Авг-18, (66)

Я сам линуксоид, но SELinux - переусложненная хрeнь, которая, мягко говоря, не у, Аноним (42), 22:48 , 29-Июл-18, (42)

Не знают и не могут знать man pamman nss, Аноним (44), 00:24 , 30-Июл-18, (44) +1

А это как раз много 171 хорошего 187 говорит об архитектуре PAM и NSS Когда , PereresusNeVlezaetBuggy (ok), 01:32 , 30-Июл-18, (47)

Вообще-то это называется API и information hiding Приложение должно знать т, Crazy Alex (ok), 19:15 , 30-Июл-18, (55)

Это было бы information hiding, если бы таковые форки, открытие файловых дескрип, PereresusNeVlezaetBuggy (ok), 19:42 , 30-Июл-18, (57)

Ты бы ещё LD_PRELOAD вспомнил, Аноним (50), 03:00 , 30-Июл-18, (49)

И маленький ньюанс Для ускорения всего и вся занесли чать Самбы в ядро ну чтоб , КО (?), 10:16 , 30-Июл-18, (53) +1

SELinux -- это не костыльный вариант Это классический корпоративный оверинжинир, Ordu (ok), 04:11 , 30-Июл-18, (51) //

Который при этом так же классчиески работает в корпоративных системах, не привяз, Crazy Alex (ok), 19:17 , 30-Июл-18, (56) +1

Да-да, я о том же Корпоративный оверинжиниринг, попытка решить 200 проблем одн, Ordu (ok), 22:04 , 30-Июл-18, (58) +2

1 SELinux появился куда позднее, скажем, systrace 8212 который в OpenBSD уже, PereresusNeVlezaetBuggy (ok), 20:41 , 29-Июл-18, (33) –1 //

и тут я немного наврал хотя systrace был добавлен в OpenBSD в 2002 году, а , PereresusNeVlezaetBuggy (ok), 21:21 , 29-Июл-18, (39)

А ограничения наследуются дочерними процессами , Ordu (ok), 22:24 , 29-Июл-18, (41) +1 //

Тоже задался таким вопросом Можно было бы написать шелл-враппер для старта прог, антончик (?), 00:13 , 30-Июл-18, (43) //

Получается с unveil нужно еще системное приложение писать, для программ которые , Аноним (52), 06:48 , 30-Июл-18, (52) //

Написать можно, но смысл теряется немалая часть путей при типовом использовании, PereresusNeVlezaetBuggy (ok), 13:07 , 30-Июл-18, (54)

Для pledge это определяется вторым аргументом, он позволяет задать ограничения и, PereresusNeVlezaetBuggy (ok), 01:36 , 30-Июл-18, (48) +1

подпишусь ка я , Урри (?), 13:14 , 31-Июл-18, (61)
Тео видимо на тяжелые наркотики с пива перешел , Daemon (??), 23:25 , 01-Авг-18, (64)

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

23. "В OpenBSD предложен новый системный вызов unveil() для изоля..." –2 +/–

Сообщение от Аноним (23), 29-Июл-18, 16:06

когда хотели изобрести SELinux, но не догадались вынести список файлов в отдельный конфиг, чтобы не патчить весь софт.

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

25. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от Аноним (28), 29-Июл-18, 17:02

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

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

26. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от anonymous (??), 29-Июл-18, 18:00

Когда кто-то хотел сумничать, но громко напузырял. Пути сцеплены с логикой приложения. И разделять их можно только от безисходности (это база проектирования любой системы), собственно selinux и реализует костыльный вариант.

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

29. "В OpenBSD предложен новый системный вызов unveil() для изоля..." –4 +/–

Сообщение от Аноним (29), 29-Июл-18, 19:27

Что в SELinux костыльного? Реализация в ядре, гибкая настройка всего и всея в юзерспайсе. Опенбздишнекам стоило бы поучиться, а не дрчить протезной лапой, как обезьяна в "Кремниевой долине"

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

30. "В OpenBSD предложен новый системный вызов unveil() для изоля..." –1 +/–

Сообщение от adaww (?), 29-Июл-18, 19:45

чувааак ! тут недавно нет бсд 8 вышла...;) с тем же pkgsrc...не нравится опенка ибашЪ юзай ее или фрю. и не иби мозги...

Ответить | Правка | Наверх | 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() недалеко.

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

37. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от Аноним (31), 29-Июл-18, 20:55

В лялихе не через pledge, там seccomp.

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

38. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 21:07

Угу. К SECCOMP ещё несколько лет назад была масса вопросов (вроде возможности отыграть назад, фактически, выключая seccomp), сейчас — может, под давлением pledge? — часть из них решилась.

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

40. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +1 +/–

Сообщение от Аноним (31), 29-Июл-18, 21:28

Насчет отыграть не в курсе — можно ссылку?

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

46. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 01:29

PR_SET_NO_NEW_PRIVS появился в 3.5 только, если я правильно разобрался.

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

60. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от A. Stahl Is Gay (?), 31-Июл-18, 13:04

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

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

63. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 31-Июл-18, 13:25

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

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

34. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 29-Июл-18, 20:43

В OpenBSD механизмы ограничения системных вызовов были тогда, когда на Linux не было вообще ничего подобного. Это уже далеко не первое поколение.

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

65. "В OpenBSD предложен новый системный вызов unveil() для изоля..." –1 +/–

Сообщение от Аноним (65), 05-Авг-18, 23:50

RSBAC, позволяющий ограничить все что угодно в линухе, появился в 2000 году. В то время опенок еще даже не был в состоянии загрузится на реальном железе(впрочем и сейчас с железом которому менее 10 лет у опенка жесткие проблемы).
А ты продолжай врать.

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

66. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 06-Авг-18, 02:22

1. «Появился» он в виде патча, а не в mainline ядре. Напомните, когда он стал частью дефолтного ядра в каком-либо крупном дистрибутиве? Потому что сравнивать доступный где-то патч и изначально доступную и работающую функциональность как-то некорректно, не находите?
Впрочем, я уже поправился по соседству, говоря про SELinux, — надо было здесь тоже, признаю.
2. OpenBSD работал на реальном железе и куче архитектур с момента рождения. В отличие от изначально x86-only Linux (я очень рад за ядро Linux, что сейчас оно может куда больше, чем в 1995-м). «А ты продолжай врать».

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

42. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от Аноним (42), 29-Июл-18, 22:48

Я сам линуксоид, но SELinux - переусложненная хрeнь, которая, мягко говоря, не украшает стек. Костыльного в ней то, что профили по умолчанию долго пилились методом проб и ошибок в стиле "Запускаем нечто, оно вылетает. Ого, оно оказывается еще и такой доступ требует? Даем!" Это позорище! Профиль безопасности должен быть частью самого приложения, авторы лучше знают, что приложению надо. Так что даешь unveil(), но только более мощный.

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

44. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +1 +/–

Сообщение от Аноним (44), 30-Июл-18, 00:24

Не знают и не могут знать.
man pam
man nss

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

47. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 01:32

А это как раз много «хорошего» говорит об архитектуре PAM и NSS.
Когда библиотека начинает делать за спиной приложения невесть что, жди беды. Круче PAM только QtWebEngine, который форкает процессы.

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

55. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от Crazy Alex (ok), 30-Июл-18, 19:15

Вообще-то это называется "API" и "information hiding". Приложение должно знать то, что оно само делает. Как именно работают используемые им сервисы, оно знать и не должно. В том числе и куда они лезут - это уровень системы.

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

57. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 19:42

> Вообще-то это называется "API" и "information hiding". Приложение должно знать то, что
> оно само делает. Как именно работают используемые им сервисы, оно знать
> и не должно. В том числе и куда они лезут -
> это уровень системы.
Это было бы information hiding, если бы таковые форки, открытие файловых дескрипторов и прочая, и прочая не влияли бы на работу приложения. Но ведь они влияют! В любой момент, получается, могут оказаться открыты только что закрытые файловые дескрипторы; обработчик сигнала может оказаться затёрт, или наоборот, оказаться вызванным в неожиданном окружении; состояние глобальной переменной может измениться; неожиданно окажется взятой какая-то блокировка (ручкой машет дед Лок), и ещё много вызывающих сбои ситуаций.
Позиция «если вы вызовете эту функцию, то может произойти всё, что угодно, а если не вызовете — тем более, ваше приложение не может ни на что рассчитывать» удобна только для того, кто такое API реализует, но не для разработчика приложения, который не может более гарантировать пользователю корректную работу своей программы при одних и тех же настройках программы и под одной и той же ОС. Как следствие, головная боль появляется у пользователя/админа, что как бы противоречит исходной задаче, решаемой ИТ — делать пользователям хорошо.
Так что далеко не всякая абстракция является качественной, увы.

Ответить | Правка | Наверх | 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() для изоля..." +/–

Сообщение от Ordu (ok), 30-Июл-18, 04:11

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

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

56. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +1 +/–

Сообщение от Crazy Alex (ok), 30-Июл-18, 19:17

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

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

58. "В OpenBSD предложен новый системный вызов unveil() для изоля..." +2 +/–

Сообщение от Ordu (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...

Ответить | Правка | Наверх | 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-м.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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


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


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


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


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


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


	63. "В OpenBSD предложен новый системный вызов unveil() для изоля..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 31-Июл-18, 13:25
	> Если я правильно понял описание, то это для того, чтобы потомки не > могли делать то, что не может делать родитель. И это тоже, так как в seccomp, насколько помню, привилегии просто наследуются. В pledge же можно явно задать привилегии именно для exec'нутых процессов. Если ошибаюсь, прошу поправить. :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


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


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


	57. "В OpenBSD предложен новый системный вызов unveil() для изоля..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 30-Июл-18, 19:42
	> Вообще-то это называется "API" и "information hiding". Приложение должно знать то, что > оно само делает. Как именно работают используемые им сервисы, оно знать > и не должно. В том числе и куда они лезут - > это уровень системы. Это было бы information hiding, если бы таковые форки, открытие файловых дескрипторов и прочая, и прочая не влияли бы на работу приложения. Но ведь они влияют! В любой момент, получается, могут оказаться открыты только что закрытые файловые дескрипторы; обработчик сигнала может оказаться затёрт, или наоборот, оказаться вызванным в неожиданном окружении; состояние глобальной переменной может измениться; неожиданно окажется взятой какая-то блокировка (ручкой машет дед Лок), и ещё много вызывающих сбои ситуаций. Позиция «если вы вызовете эту функцию, то может произойти всё, что угодно, а если не вызовете — тем более, ваше приложение не может ни на что рассчитывать» удобна только для того, кто такое API реализует, но не для разработчика приложения, который не может более гарантировать пользователю корректную работу своей программы при одних и тех же настройках программы и под одной и той же ОС. Как следствие, головная боль появляется у пользователя/админа, что как бы противоречит исходной задаче, решаемой ИТ — делать пользователям хорошо. Так что далеко не всякая абстракция является качественной, увы.
	Ответить \| Правка \| Наверх \| 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() для изоля..."	+/–
	Сообщение от Ordu (ok), 30-Июл-18, 04:11
	> собственно selinux и реализует костыльный вариант. SELinux -- это не костыльный вариант. Это классический корпоративный оверинжиниринг.
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


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


	58. "В OpenBSD предложен новый системный вызов unveil() для изоля..."	+2 +/–
	Сообщение от Ordu (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...
	Ответить \| Правка \| Наверх \| 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-м.
	Ответить \| Правка \| Наверх \| Cообщить модератору