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

Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD, opennews (??), 16-Фев-20, (0) [смотреть все] Но как же хвалёное внимание BSD-шников к безопасности , Аноним (1), 08:44 , 16-Фев-20, (1) +4 // непрерывный аудит и находит такие ошибки, б.б. (?), 08:50 , 16-Фев-20, (2) +3 // Да, тут было бы интересно узнать, какое время эта уязвимость просидела незамечен, Андрей (??), 18:26 , 16-Фев-20, (32) –2 // судя по тому, что патч вышел для 6 6, но не вышел, как обычно, для 6 5, значит у, б.б. (?), 07:15 , 17-Фев-20, (49) Но тогда получается что линуксоиды со своим syzkaller ом и сотнями тестов, аудит, Аноним (-), 20:30 , 16-Фев-20, (38) // Отдельные линуксоиды опеннета, по понтам -- так уж точно , Аноним (-), 22:52 , 16-Фев-20, (43) +1 У кого ж они этому научились Вроде, говорят что BSD до Linux появились , Аноним (-), 23:12 , 16-Фев-20, (44) И часовню - тоже они , Аноним (-), 00:37 , 17-Фев-20, (46) BSDшники написали Unix, да , Аноним (51), 11:48 , 17-Фев-20, (51) Скрыто модератором, Аноним (-), 15:11 , 17-Фев-20, (56) Авотфиг Вон там Euler Linux таки сертифицЫровли как UNIX facepalm А бздов в, Аноним (-), 22:43 , 20-Фев-20, (92) Да , Аноним (60), 17:22 , 17-Фев-20, (60) syzkaller ом и сотнями тестов, аудитов и фуззинга не гарантируют нахождение ошиб, Аноним (61), 17:47 , 17-Фев-20, (61) Стопроцентные гарантии в этом мире даже страховой полис, увы, не дает Работает , Аноним (-), 21:13 , 17-Фев-20, (65) Так вот же оно - были столь внимательны, что обнаружили очередную уязвимость , Валик (?), 08:52 , 16-Фев-20, (3) +2 BSD большой и все 1782 4 BSDшника не смогут выловить все баги до очередного рел, A.Stahl (ok), 08:54 , 16-Фев-20, (4) // По-моему, ваша оценка числа разработчиков опёнка сильно завышена На пару порядк, Аноним (51), 11:50 , 17-Фев-20, (52) Активных разработчиков OpenBSD одномоментно порядка 70, всего 8212 несколько , Аноним (67), 21:35 , 17-Фев-20, (67) Тео изначально сказал что защита памяти в опенке будет не строгая, а со щелями , Аноним (6), 08:58 , 16-Фев-20, (6) // А есть пруфы , Аноним (22), 13:23 , 16-Фев-20, (22) +1 // Были, надо искать, даже здесь писали Смотри планы по защите памяти в опенке, осо, Аноним (68), 08:49 , 18-Фев-20, (68) paxtest запусти , Аноним (68), 09:54 , 18-Фев-20, (74) https security stackexchange com questions 139238 why-does-paxtest-show-openbs, Аноним (68), 09:58 , 18-Фев-20, (75) Так говорил Заратустра , xm (ok), 16:19 , 16-Фев-20, (25) Сейчас тебе расскажут, что поэтому и находят уязвимости, что внимательно следят, llol (?), 11:59 , 16-Фев-20, (20) –2 // Дегенераты из линуксового мира до сих пор не могут понять что основные BSD это , xm (ok), 16:21 , 16-Фев-20, (26) // Знаете, я не специалист по таким состояниям, но Вашу мысль можно было переформул, Michael Shigorin (ok), 18:18 , 16-Фев-20, (30) –5 Жителю Санкт-Петербурга простительно не понимать тонкой разницы между чеченцем и, Аноним (51), 11:51 , 17-Фев-20, (53) Жителям Санкт-Петербурга прежде чем искать всякого рода тонкие разницы недур, xm (ok), 13:07 , 17-Фев-20, (54) Да вот знаете, если так посмотреть кто в парадных ссыт, у них почему-то обычно ч, Аноним (-), 15:23 , 17-Фев-20, (57) Во-первых, не BSD-шников , а опёнковцев Во-вторых, на всякого Акелу в сходяще, Michael Shigorin (ok), 18:13 , 16-Фев-20, (29) –1 // При том если Акелла вдруг удумает лечить что, например, виртуализация не нужна -, Аноним (39), 20:34 , 16-Фев-20, (39) –1 // Потому что аноним, как обычно, слышал звон И ЧСЗ, самозабвенно повторяет его уж, Аноним (45), 23:14 , 16-Фев-20, (45) +1 Во первых, я видел виртуализаторы самого разного пошиба в продакшнах и тестлабах, Аноним (-), 04:50 , 17-Фев-20, (48) –2 Разве что в параллельной вселенной Ну или все эти ваши жирные корпорации с мир, Аноним (-), 14:45 , 17-Фев-20, (55) Это годные сельпо, оно завалили глобус продукцией С хорошей вероятностью вы их , Аноним (-), 16:51 , 17-Фев-20, (58) Вряд ли Два комментария с морем пафоса, воды, повторов одно и того же на разные , анонн (ok), 18:40 , 17-Фев-20, (63) Мегакорпорации штука забавная - ухитряются пролезть в самые неожиданные области , Аноним (-), 21:34 , 17-Фев-20, (66) В OpenBSD защита памяти сделана хуже чем в Linux PAX GrSecurity https pax , Аноним (6), 08:56 , 16-Фев-20, (5) // В дополнение к защите памяти с помощью классических R, W, X, UNIX должен защищат, Аноним (6), 09:13 , 16-Фев-20, (8) +1 // мы выслушали очередную рекламу Grsec не осилившего прочитать штатные средства за, Аноним (13), 09:24 , 16-Фев-20, (13) +6 // После Grsecurity, Аноним (61), 17:50 , 17-Фев-20, (62) да да, вот шнурки отглажу тогда уж grsec спер из Virtuozzo Linux-VServer, Аноним (64), 20:51 , 17-Фев-20, (64) мы выслушали очередную рекламу grsec Как там в у вас с нарушениями GPL , Аноним (13), 09:22 , 16-Фев-20, (11) +2 // https www opennet ru openforum vsluhforumID3 119728 html 31https www opennet, Аноним (6), 09:32 , 16-Фев-20, (14) +1 The restrictions prevent - creating executable anonymous mappings - creatin, Аноним (6), 09:22 , 16-Фев-20, (12) Конечно же, вы правы Только хотелось бы уточнить, почему пользователей дистрибу, Аноним (67), 11:06 , 16-Фев-20, (18)   // Хорош вопрос Вернемся к истокам и вспомним историю первого безопасного дистрибут, Аноним (19), 11:57 , 16-Фев-20, (19)   // Это был линукс , Consta (?), 12:50 , 16-Фев-20, (21) +1   Да, GNU Linux, но с расширенными возможностями ядра, компилятора, глибс и бинути, Аноним (68), 09:00 , 18-Фев-20, (69)   Это не спасает Дело не только в формальной матмодели как таковой как в совокуп, Consta (?), 17:41 , 18-Фев-20, (80)   Много писать не хочется, буду краток 1 Если идти путем разработки микроядра с т, Аноним (83), 16:58 , 19-Фев-20, (83)   Зачем Там свое Кроме того, я не предлагал такое Смысл моего прсыла был в том,, Consta (?), 13:47 , 20-Фев-20, (89)   Доказано что любая реализация DAC и MAC в микроядерных OS будет работать более ч, Аноним (101), 11:48 , 22-Фев-20, (101) –1   Где можно ознакомиться с соответствующими доказательствами Может, хоть у меня п, Consta (?), 15:06 , 22-Фев-20, (102)   Мы когда-то посовещались и Я так решил https www opennet ru openforum vsluhfor, Аноним (114), 16:43 , 26-Фев-20, (114)   - Вы не хотите настроить простую DAC, спорите о том, что можно выделять память о, Аноним (114), 17:25 , 26-Фев-20, (117)   Правильно понимаю, что предлагается в качестве доказательств рассматривать ссылк, Consta (?), 15:24 , 02-Мрт-20, (130)   Там вполне достаточно чтобы сложить 2 2 Дополнения для безопасности Писал уже, c, Аноним (135), 16:24 , 04-Мрт-20, (135)   Да я и не сомневался, что сразу все ясно Решение, безусловно, новаторское Снач, Consta (?), 11:12 , 06-Мрт-20, (146)   Нет времени спорить и что то доказывать Это сложные вещи Кратко Сетевой экран, , Аноним (147), 12:40 , 07-Мрт-20, (147)   Теперь это Астра , pin (??), 13:42 , 16-Фев-20, (23)   Если вдруг Вы угадали -- то было бы особенно пикантно, потому как несколько лет , Michael Shigorin (ok), 18:27 , 16-Фев-20, (33)   Нет не Астра , Аноним (68), 09:01 , 18-Фев-20, (70)   Спектре матмодель учитывала , cutlass (?), 14:59 , 16-Фев-20, (24) +3   Это было 10 лет назад , Аноним (68), 09:02 , 18-Фев-20, (71)   На ентерпрайз-дистрибутивах можно неплохо попилить, а на твоей разработке как , Аноним (27), 16:23 , 16-Фев-20, (27) +2   Во-первых, если он и претендовал на первый безопасный , это была ложь Во-вторых, Michael Shigorin (ok), 18:24 , 16-Фев-20, (31)   Всё уже придумано полвека назад, но только не бздунами под дырявую платформу htt, tensor (?), 19:57 , 16-Фев-20, (36)   Да, в донкихотство теперь не верит даже Газпром, им видимо донесли что бюджет вс, Аноним (-), 17:00 , 17-Фев-20, (59) +1   Речь шла об ОС общего назначения , Аноним (68), 09:10 , 18-Фев-20, (72)   В ос общего назначения крапа слишком уж много, все предусмотреть имхо малореальн, Аноним (81), 01:00 , 19-Фев-20, (81) +1   Она, главным образом, сделана по другому И OpenBSD, в отличие от NetBSD и Harde, Дон Ягон (ok), 20:18 , 16-Фев-20, (37) +3 // Спасибо за расширенный ответ Неизыблемое правило DAC - все исполняемое не должно, Аноним (68), 09:50 , 18-Фев-20, (73) –2 // Это которая с питоном и шеллскриптами, умеющими в eval и чьи интерпрета, анонн (ok), 13:27 , 18-Фев-20, (77) +2 Интерпретаторы, с питоном включительно, можно обрезать простым DAC Обычному пол, Аноним (83), 17:24 , 19-Фев-20, (84) Угу, обрежь пакетный менеджер простым DAC И чего он сможет потом А ежели это, Аноним (-), 22:54 , 20-Фев-20, (93) +1 Именно так и надо делать Пакетным менеджером должен рулить отдельный пользовате, Аноним (101), 09:07 , 22-Фев-20, (98) А как насчет простого тезиса Подлом этого юзера почти эквивалентен подлому рута, Аноним (-), 21:11 , 01-Мрт-20, (127) О, а попробуйте так сделать вот прям сейчас на localhost Разумеется, используемо, Michael Shigorin (ok), 16:18 , 22-Фев-20, (103) У меня именно так все и настроено Пользователям права на их shell даю На остал, Аноним (114), 16:48 , 26-Фев-20, (115) Это общеиспользуемые стандарты, других нет Реальность, увы, иная JIT используе, Дон Ягон (ok), 14:31 , 18-Фев-20, (78) +1 del, Дон Ягон (ok), 14:50 , 18-Фев-20, (79) Желаю все оптимизировать во время компиляции под свой проц, а во время исполнени, Аноним (83), 17:54 , 19-Фев-20, (85) Это желания и только Реальность есть реальность Некоторые подвижки есть, но и , Дон Ягон (ok), 07:48 , 20-Фев-20, (87) У меня source based дистрибутив вопрошающий мои желания в реальность И по этому , Аноним (101), 10:45 , 22-Фев-20, (99) Нет, это не так Было бы хорошо, если бы это было так, но это не так и игнориров, Дон Ягон (ok), 06:31 , 23-Фев-20, (105) Потому что никто не хочет лепить свои костыли вместо стандартных возможностей ff, Аноним (114), 17:09 , 26-Фев-20, (116) Пример, который я описывал был не про обход W X pt 2 pax mprotect , а про обход, Дон Ягон (ok), 23:29 , 26-Фев-20, (118) Рандомизацтя адресного пространства сильно затрудняет поиск нужного кода Ты не с, Аноним (119), 16:01 , 27-Фев-20, (119) Я про это, да Я не про это Божечки, да причём тут это Когда-то у меня был арч с , Дон Ягон (ok), 16:11 , 27-Фев-20, (120) Мое мнение, контроль за памятью должен быть только у ядра Изменение исполняемых, Аноним (121), 15:44 , 28-Фев-20, (121) Ради бога Почему я считаю, что такой максималистский подход малоприменим для вс, Дон Ягон (ok), 15:49 , 28-Фев-20, (122) Надеюсь, что всем уже стало понятно необходимость, ядром OS или аппаратно процес, Аноним (123), 09:07 , 29-Фев-20, (123) Я прочитал сейчас что-то, по меньшей мере, очень странное И в случае pledge, и в, Дон Ягон (ok), 05:07 , 01-Мрт-20, (124) Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям и, Аноним (126), 15:26 , 01-Мрт-20, (126) Прости, но ты пишешь ахинею Pledge - это системный вызов, как следствие, вся ра, Дон Ягон (ok), 00:44 , 02-Мрт-20, (129) Плохо то, что есть в ядре OpenBSD возможность дать программ право изменять испол, Аноним (131), 15:51 , 02-Мрт-20, (131) Нет, это не плохо, это адекватно требованиям, выдвигаемым к ОС общего назначения, Дон Ягон (ok), 16:10 , 02-Мрт-20, (132) Нет сегодня возможности проверить логику работы всех программ А безопасность им, Аноним (133), 15:55 , 03-Мрт-20, (133) Ну, я к тому, что можно и заканчивать Кажется, друг друга мы поняли, друг с дру, Дон Ягон (ok), 16:05 , 03-Мрт-20, (134) Вы не сказали самый главный аргумент против использования W X А его надо понима, Аноним (135), 16:38 , 04-Мрт-20, (136) ИМХО, это всё совсем не про ОС общего назначения И даже не только лишь по требо, Дон Ягон (ok), 16:41 , 04-Мрт-20, (137) Про OS общего назначения это Реализация PaX в GNU Linux очень правильная и преду, Аноним (135), 16:48 , 04-Мрт-20, (138) Я понял На эту тему все мысли, которые у меня были я уже написал, больше не х, Дон Ягон (ok), 17:20 , 04-Мрт-20, (139) Классика жанра В спец ПО для райнимации больного допустили ошибку переполнения б, Аноним (140), 17:41 , 04-Мрт-20, (140) Логика рассуждения мне понятна, спасибо Мне не понятно, почему бы не резервиров, Дон Ягон (ok), 17:58 , 04-Мрт-20, (141) А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще , Аноним (144), 16:31 , 05-Мрт-20, (144) Всё зависит от того, как именно всё реализовано Мы этих моментов не уточнили - , Дон Ягон (ok), 17:06 , 05-Мрт-20, (145) +1 Например, переключатель может быть вообще исполнен в железе Есть общая теория пр, Аноним (148), 14:28 , 07-Мрт-20, (148) А кто за лоббирование бесполезной для жизни и очень вредной для безопасности, те, Аноним (68), 10:02 , 18-Фев-20, (76) Типичная апологетика и двойные стандарты Зато соответствует модели угроз с учёто, недобрый (?), 07:49 , 19-Фев-20, (82) // При чём тут мои критерии Приложения хромиум, java перестанут работать Лично , Дон Ягон (ok), 07:27 , 20-Фев-20, (86) Что ты тут ёрничаешь Перестанут работать, только если не будет способа снять дл, недобрый (?), 12:06 , 20-Фев-20, (88) Ну то есть ещё раз если для некоторых приложений не ОТКЛЮЧИТЬ pax-защиты, они р, Дон Ягон (ok), 17:55 , 20-Фев-20, (90) А если отключить - будут Ещё раз это whitelisting, лучшая практика по индустри, недобрый (?), 22:33 , 20-Фев-20, (91) Вместо решения конкретных проблем - мантры о стандартах индустрии В случае проб, Дон Ягон (ok), 06:34 , 21-Фев-20, (94) ничего себе тут войну и мир пишут можно уже на бумаге издавать, б.б. (?), 08:04 , 21-Фев-20, (95) Это ты сейчас свои отсылки к стандартам хорошо охарактеризовал Да мне всё равно,, недобрый (?), 12:48 , 21-Фев-20, (96) Это твои домыслы В первом комментарии речь шла не про paxd и прочие костыли, чт, Дон Ягон (ok), 06:22 , 22-Фев-20, (97) Ты не читатель ты, судя по этому посту писатель https www opennet ru openf, Аноним (101), 10:59 , 22-Фев-20, (100) Не домыслы, а хорошо обоснованные выводы Уродство - слово литературное Потом ты, недобрый (?), 20:11 , 24-Фев-20, (106) Извини, но далее я буду стараться отвечать только на то, на что есть смысл отвеч, Дон Ягон (ok), 03:29 , 25-Фев-20, (109) Очевидно, что не безразлично Но мне удобнее, чтобы ты не слился, а наоборот про, недобрый (?), 10:47 , 26-Фев-20, (110) Ты можешь быть уверен в чём угодно - я не против Во всех ОС общего назначения по, Дон Ягон (ok), 15:54 , 26-Фев-20, (112) Это ты на словах не против А на деле две недели упражняешься в зарабатывании пр, недобрый (?), 20:42 , 04-Мрт-20, (142) Рассуждать отказался Ну, кто бы сомневался И это твоё замечание могло бы иметь , недобрый (?), 20:44 , 04-Мрт-20, (143) Вопрос выбора абстракций определений Как по мне, меры защиты должны быть реакцие, Дон Ягон (ok), 15:58 , 26-Фев-20, (113) Сразу - это прям сразу Значит, у тебя в голове вместо целостной картины не один, недобрый (?), 10:50 , 26-Фев-20, (111) А где я утверждал, что делали неосознанно и что чинить надо В OpenBSD пусть хот, недобрый (?), 20:13 , 24-Фев-20, (107) Это где _пакетный менеджер_ ругается на битые чексуммы у _пакета_ Если пакетный , недобрый (?), 20:17 , 24-Фев-20, (108) Скрыто модератором, Аноним (9), 09:15 , 16-Фев-20, (9) –13 // Скрыто модератором, neAnonim (?), 09:53 , 16-Фев-20, (15) +5 Скрыто модератором, Ананимус (?), 10:14 , 16-Фев-20, (16) +5 Скрыто модератором, Аноним (17), 10:52 , 16-Фев-20, (17) +2 Скрыто модератором, pda (?), 18:09 , 16-Фев-20, (28) +1 Скрыто модератором, Michael Shigorin (ok), 18:30 , 16-Фев-20, (34) // Скрыто модератором, Аноним (39), 20:37 , 16-Фев-20, (40) // Скрыто модератором, Michael Shigorin (ok), 21:10 , 16-Фев-20, (41) Скрыто модератором, Аноним (-), 21:20 , 16-Фев-20, (42) –1 А ещё лет 10 назад на опеннете Да кому ты нужен, зачем фаервол настраивать, заче, Аноним (35), 18:37 , 16-Фев-20, (35) // 10 лет назад ещё не изобрели китайцев Некомпетентные люди существуют во все вре, Аноним (47), 03:45 , 17-Фев-20, (47) Если помечено уже read-only кем-то третьим, то зачем же второй раз уже самому за, Аноним (50), 08:08 , 17-Фев-20, (50) https marc info l openbsd-tech m 158237030723610 w 2Трололо, там с первого ра, Дон Ягон (ok), 22:33 , 22-Фев-20, (104) // https www opennet ru opennews art shtml num 52418, Аноним (126), 14:30 , 01-Мрт-20, (125) // Спасибо, видел Мой комментарий был раньше, когда я ещё не знал, что Максим план, Дон Ягон (ok), 23:16 , 01-Мрт-20, (128) 1,5,35,50,104

Сообщения

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

	18. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (67), 16-Фев-20, 11:06
	Конечно же, вы правы. Только хотелось бы уточнить, почему пользователей дистрибутивов Linux, где PaX и GRSecurity включены по умолчанию, так мало по сравнению с остальными?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	19. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (19), 16-Фев-20, 11:57
	Хорош вопрос! Вернемся к истокам и вспомним историю первого безопасного дистрибутива Linux - Adamantics. Его автор пропал без вести в ЕС... Когда grsecurity в мутной истории с мутными договорами и требованием оплаты в нарушение лицензии GPL-2 закрыли патчи для свободного скачивания дистрибутивов с grsecurity, PAX стало еще меньше. В РФ есть проблема образования - ИТ безграмотность. Лет 10 назад устраивался на работу в Газпром. Предлагал им разработку, внедрение и поддержку безопасной ОС, основанной на мат модели, которая дает определенные гарантии безопасности. Мы так и не подписали договор, ибо они считают, что ИТ безопасность можно достичь исключительно мозгоебством, используя ынтерпрайз дистрибутивы. А мат модель которая даст гарантии не зависимо от любых действий пользователя они понять пока не могут, а поверить уже не хотят.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Consta (?), 16-Фев-20, 12:50
	>> Предлагал им разработку, внедрение и поддержку безопасной ОС, основанной на мат модели... Это был линукс?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (68), 18-Фев-20, 09:00
	Да, GNU/Linux, но с расширенными возможностями ядра, компилятора, глибс и бинутилс.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Consta (?), 18-Фев-20, 17:41
	>> Предлагал им разработку, внедрение и поддержку безопасной ОС, основанной на мат модели... >> Да, GNU/Linux, но с расширенными возможностями ядра, компилятора, глибс и бинутилс Это не спасает. Дело не только в формальной\матмодели как таковой (как в совокупности формальных\математических доказательств). Дело прежде всего в реализации как таковой. Чтобы реализация точно соответствовала модели. Чтобы все работало так, как требует математика. А для линукс это вряд ли возможно. 1. Вы пишете: "основанной на матмодели". Но сложность именно в том, что Linux никогда и не основывался на матмодели. Позволю себе напомнить, что сам Торвальдс в своей книге "Just for Fun" (если правильно помню - 10 и 11 главы) неплохо описывает полемику с Танненбаумом про микроядро. Для микроядра формальная матмодель возможна в реальности (здесь "в реальности" я имею ввиду реализацию, а не просто декларацию в виде формул), наверное, как и ее верификация. В линуксе же - нет. Ибо вопросы формализации матмодели для Linux возможны только на бумаге. Например, можно "натянуть" матмодель типа HRU для DAC (тут я понимаю как, даже с ACL). Но тогда что делать с capabilities? Выносить за рамки модели? Или пускай пухнет множество? Можно, наверное, "натянуть" пресловутую модель Bella и LaPadula. Но это будет справедливая модель, описывающая MLS - т.е. только для SELinux, ну, или, parsec (хе-хе). Но тогда вопрос - а что делать c DAC? Не учитывать? Плюс ко всему - в ядре линукс (в зависимости от реализации и архитектуры) примерно 350-450 системных вызовов. Примерно сотни полторы из которых совершенно точно security relevant. Если не больше. Что с ними всеми делать? Что делать со всякими namespaces, которые довольно дырявые до сих пор и постоянно переписываются? Что делать с моделью, которая должна описывать движение информационных потоков? А ведь это ведет за собой моделирование и NetFilter тоже. То есть потребется промоделировать безопасное состояние системы с огромным количеством атрибутов и операций. Плюс аудит. Плюс функции и сисколы, ответственные за время. И т.д. и т.п. Пока будем писать модели и проверять их корректность - это несколько лет пройдет и чудовищное количество человеко-часов. Запросто получим изменения в реализации. 2. Чтобы реально, а не на бумаге получить безопасную систему требуется представление реализации, в точности воспроизводящее формальную\матмодель. Реализация же не только сисколлов (как интерфейсов к функциям), а и самих функций и структур данных - чудовищно большая и размазана по ядру (и не только ядру), точек входа много. Достаточно посмотреть на количество поддерживаемых ФС и их связку с VFS, чтобы понять что монитор обращений не так то просто не то что формализовать и проверить, а хотя бы просто описать. Кроме того, напомню, что институт системного программирования РАН пытался несколько лет верифицировать сисколлы. Но не закончили, так и бросили. До функций даже и не дошли. Плюс - чудовищный объем ядра. 3. Именно поэтому практически не встречается в CCRA не то что линукса, а и вообще юникса, имеющего сертификат выше чем EAL4+. Там чуваки серьезные и они понимают, что дальше начинается моделирование, сопоставление с представлением реализации (EAL5), а еще дальше - и верификация (EAL5+). К сожалению наш регулятор (при всем уважении) позволяет себе (по крайней мере пока) выдавать сертификаты на линукс систему, которая у нас тащит первый или второй уровень доверия (т.е. по-их нормативке выше, чем EAL5+). Именно поэтому я бы не стал думать, что в Газпроме сидят люди, глупее нас с вами. Они хорошо себе представляют, где шашечки, а где ехать. Потому и отказали. Не надо удивляться.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (83), 19-Фев-20, 16:58
	Много писать не хочется, буду краток. 1. Если идти путем разработки микроядра с текущей мат моделью UNIX, то тормоза по сравнению с монолитным ядром будут ~10 раз! В монолите поток проходит проверку ACL один раз, а в микроядра при каждом обращении к микросервисам должна проходить проверка ACL. Безопасные ОС на микроядрах будут очень сильно тормозными. DAC, MAC придется выкинуть. Хорошо работает ASLR рандомизация, будет работать Integrity. 2. В монолитных ядрах, в класической модели UNIX, разные модели безопасности применяются последовательно и друг с другом почти не взаимодействуют. Сперва применяется Integroty, потом DAC, если все проверки прошли, то применяем MAC. Реализация Integrity, DAC и MAC почти не связаны. Связь есть но минимальна. Каждая ступенька имеет свою матмодель. Эти мат модели не связаны между собой, почти. MAC от Bella и LaPadula просто подогнана под документооборот в DoD US не есть универсальна и очень сложно внедряема на обычном предприятии. MAC вообще очень дорогая штука в плане написания правил. RSBAC от grsecurity с возможностью самообучения и простым форматом правил выглядит вполне привлекательно и capabilities он тоже контролирует. Capabilities предполагает в общем еще адаптацию ПО, написание правил это тоже дорого. Можно схитрить, на уровне ядра создать изоляцию в которой capabilities запрещены и помещать туда сервисы - это дешево. Опять ПО написано криво, бинари пытаются создать каталог для логов, установить на него права... и при заруске в изоляции от capabilities ядро их убивает. Cgruops, namespaces, виртуализация мне не нравятся вообще. 3. Аудит кода трудоемок и не предполагался вообще. Кроме минимальных участков которые модифицируются. Для гарантий безопасности ОС необходимо и достаточно "контролировать", изменить: ядро, гсс, глибс, бинутилс. Газпром был тогда заинтеиесован, хотел, но мы не договорились. Я требовал гарантий полного покоя, чтобы ничего меня не отвлекало, а они соглашались только на общих условиях.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Consta (?), 20-Фев-20, 13:47
	>> Если идти путем разработки микроядра с текущей мат моделью UNIX... Зачем? Там свое. Кроме того, я не предлагал такое. Смысл моего прсыла был в том, что в сущности, при микроядре возможно достичь и в представлении реализации тех критериев безопасности, заданных формальной моделью,а не только на бумаге. >> Cgruops, namespaces, виртуализация мне не нравятся вообще. Именно на это я и указывал. Только вопрос не в том, что нравится, а что нет. Вопрос в том, что эти механизмы (плюс капабилити, конечно) - оооочень плохо формализуются (если это вообще возможно). А просто так их выкинуть не получится. Не учитывать их по желанию - это волюнтаризм чистой воды. Получаем неописанные ФБО в ядре, т.е., соответственно - НДВ, в чистом виде. А ведь капабилити это дискретка, которую надо бы заявлять, ибо она есть. Ну, или иначе выкидывать. >> MAC от Bella и LaPadula просто подогнана под документооборот в DoD... Нет. Это вовсе не так. Это просто хорошая, стррйная и простая формальная модель разграничения доступа и информационных потоков. То, что она применялась (точнее, реализация на ее базе) в DoD (и не только) - лишнее тому подтверждение. >> Аудит кода трудоемок и не предполагался вообще. Кроме минимальных участков которые модифицируются. Если аудит не предполагался, то как тогда планировалось убедиться в достижении критериев безопасности, заданных формальной моделью при реализации в коде? Неужели на бумаге? Я уже указывал, что минимальных участков там нет и не будет. Это слова. Напоминаю, что функции, реализующие ФБО валяются в ядре ооооочень много где. Это совершенно точно сотни файлов исходников. Плюс - заголовочные файлы и файлы со структурами данных. Плюс, сюда надо добавить интерфейсы в виде сисколов, а это еще несколько десятков файлов, минимум. Плюс нетфильтр. Плюс - убедится в корректности работы интерфейсов, например, с помощью LTP тестов. Но они есть не на все сисколлы и не по всем входным/выходным данным. То есть там покрытие не стопроцентное, не позволяющее проверить все множество работы интерфейсов к функциям. Значит, надо дописывать тесты. Плюс, выполнить дальнейшее прослеживание, которое при проверке, скажем, команды chmod покажет, что дергается нужный сискол chmod(). А это значит, что и командные интерфейсы тоже надо исследовать и проверять. Одними бинутилсами и глибси в юзерспейсе не обойтись. В целом, гарантии в виде непонятной бумажной модели, не учитывающей все механизмы разграничения доступа и с минимальным аудитом реализации, а также постулат, что достаточно иметь ядро, глибси, компилятор и бинутилс, без учета сисколов и интерфейсов в юзерспейсе - извините, мне это тоже представляются крайне сомнительными.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	–1 +/–
	Сообщение от Аноним (101), 22-Фев-20, 11:48
	> Смысл моего прсыла был в том, что в сущности, при микроядре возможно достичь и в представлении реализации тех критериев безопасности, заданных формальной моделью,а не только на бумаге. Доказано что любая реализация DAC и MAC в микроядерных OS будет работать более чем в 10 раз медленнее по сравнению с монолитными OS! И пока нет других мат моделей заменяющих DAC и MAC, рандомизация не дает таких гарантий, в разработке микроядерных OS ставим точку. > > Cgruops, namespaces, виртуализация мне не нравятся вообще. > Вопрос в том, что эти механизмы (плюс капабилити, конечно) - оооочень плохо формализуются (если это вообще возможно). А просто так их выкинуть не получится. У меня получается эти механизмы выкинуть. С ними выкидывается сразу systemd, elogind. У вас ниукого нет никакого понимания общей безопасности ОС! В РФ об этом по чему-то никто не знает!!! Распределите все существующие модели безопасности по их ВРЕМЕНИ, ПОРЯДКУ, МЕСТУ применения в OS. Узрите что большинство применяется последовательно, а не паралельно и  можно считать независимыми друг от друга. Capabilities применяется последовательно с Integrity, сразу после нее и паралельно с DAC и MAC, но почти независимо от них, применяется ядром на всем протяжении работы программы. Оно дробит права root по областям и следит за тем чтобы не использовалось более чем заявлено самой прогой и/или разрешено ядром OS. Реализация на стороне программы дорогая. Вы не видите лес в целом ч высоты, а пытаетесь понять, что такое лес, рассматривая листочки и веточки. > > MAC от Bella и LaPadula просто подогнана под документооборот в DoD... > Нет. Это вовсе не так. Это просто хорошая, стррйная и простая формальная модель разграничения доступа и информационных потоков. То, что она применялась (точнее, реализация на ее базе) в DoD (и не только) - лишнее тому подтверждение. DoD имела свою бумажную инструкцию бумажного документооборота, а Bella и LaPadula, тупо, вместо разработки MAC для OS, сперли модель бумажного документооборота и написали по ней свой MAC. И это плохо для общего применения. > > Аудит кода трудоемок и не предполагался вообще. Кроме минимальных участков которые модифицируются. > Если аудит не предполагался, то как тогда планировалось убедиться в достижении критериев безопасности, заданных формальной моделью при реализации в коде? ... Для дачи гарантий код надо дописывать. Аудит всего кода не предполагался. Вот изменяемой, для дачи гарантий, часть кода предполагалось верифицировать с формальной мат моделью. А иначе никак, даже с ресурсами Газпрома. Людей подготовленных просто столько нет. > В целом, гарантии в виде непонятной бумажной модели, не учитывающей все механизмы разграничения доступа и с минимальным аудитом реализации, а также постулат, что достаточно иметь ядро, глибси, компилятор и бинутилс, без учета сисколов и интерфейсов в юзерспейсе - извините, мне это тоже представляются крайне сомнительными. Ниукого нет одной большой мат модели, которая учитывает все. Есть безопасность как совокупность многих методов, каждый с которых имеет свою хорошую мат модель. Есть понимание где, в каких конкретных точках все эти методы применяются: последовательно или параллельно к друг другу. Есть допущение что каждый метод безопасности почти не взаимодействует с другими и его можно рассматривать отдельной мат моделью. Общая мат модель она рассматривает, формально на бумаге, закрытие всех возможных щелей существующими методами дающими определенные гарантии безопасности и имеющими свои специфичные мат модели.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Consta (?), 22-Фев-20, 15:06
	>> Доказано что любая реализация DAC и MAC в микроядерных OS Где можно ознакомиться с соответствующими доказательствами? Может, хоть у меня получится повысть свой уровень образования. >> У меня получается эти механизмы выкинуть. Подрудитесь объяснить в таком случае еще несколько вещей: 1. Каким именно образом были выброшены namespaces, capabilities и cgroups? Что стало с сисколами, которые это обрабатывали? 2. Что после того, как выкинули указанное в п. 1 стало с совместимостью программ в пространстве пользователя? 3. Правильно ли понимаю, что в таком случае предполагалось использовать HRU модель? >> У вас ниукого нет никакого понимания общей безопасности ОС! В РФ об этом по чему-то никто не знает!!! Ну тут даже не знаю, что сказать. Видимо, до таких высот мы еще не доросли, да. Но тогда не доросли и все остальные. Ибо почему то, о ужас, у RedHat уровень доверия EAL4+, у SLES/D - тоже такой EAL4+. У Ubuntu - EAL2. Все эти уровни доверия не предполагают формализации моделей. Достаточно зачитать ISO 15408 и 18045, чтобы это понять. Очевидно, они там еще меньше нашего соображают в вопросах доверия к безопасности, правильно понимаю?  Почему то им не приходит в голову бодро писать модели и поднимать EAL. Тоже, видимо, ума не хватает. Ну, могу лишь посоветовать не теряться, и обратиться сразу в IBM, которая выступает много лет заявителем у RedHat и SUSE. Может, хоть там прислушаются к мощности аргументации, раз у нас не хватает тут ума. В целом, даже возможно лучше, как говаривал классик, писать сразу в Спортлото. Напомню, что документация на RHEL, Ubuntu и SUSE лежит в открытом доступе, где можно ознакомится с соответствующей аргументацией. Если есть сложности с поиском в гугле - то меня вовсе не затруднит выложить ссылку, например для RHEL: https://access.redhat.com/articles/2918071 Там и задания по безопасности есть, и отчетные материалы. А если порыть сайт IBM, то там лежат и функциональные спецификации и базовые модульные проекты (aka HLD). И из того что там написано, можно понять, что они совершенно не зря считают, что формальная модель для линукс плохо применима, а верификация реализации или практически невозможна, либо чудовищно трудоемка даже для IBM.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (114), 26-Фев-20, 16:43
	>> Доказано что любая реализация DAC и MAC в микроядерных OS >Где можно ознакомиться с соответствующими доказательствами? Мы когда-то посовещались и Я так решил. https://www.opennet.ru/openforum/vsluhforumID3/100354.html#51 https://www.opennet.ru/openforum/vsluhforumID3/100354.html#23 https://www.opennet.ru/openforum/vsluhforumID3/100354.html#48 https://www.opennet.ru/openforum/vsluhforumID3/103368.html#28 ACL и MAC модели для микроядер неприемлемы из-за тормозов в реализации более 10 раз. Это проблема решения не имеет и хакеры GNU Hurd это пока признают. Долго искали решения и вопрос с производительностью ACL и MAC отложили. Тесты сравнения производительности ACL в Hurd и Linux были здесь. Проиграш микроядра по сравнению с монолитом 10-100 раз. Хакеры Haiku отказались от безопасности ACL и MAC в пользу производительности. seL4 первая реализация микроядра, которая дает хоть какую-то гарантию безопасности без потери производительности в сравнении с монолитом. Безопасность основана на рандомизации. ACL и MAC в ней нет. Сам подумай, при каждомм выходе-входе в микроядро надо делать все проверки ACL и MAC! Монолитное ядро делает в контексте ядра только одну проверку и реализует сразу очень большие возможности: драйвера, протоколы, шифрование, .... > namespaces, capabilities и cgroups capabilities я выбрасывать нигде не говорил! Говорил что поддержка capabilities, как вы ее предлагаете, очень дорога. Говорил, что программисты включают установку прав на log, run в бинарный сервис, а надо в инит скрипт. Также показал правильный путь использования capabilities - RSBAC от grsecurity. Ничего писать не надо они capabilities контролируют правилами RSBAC сразу для всех прог. Отключение cgroups прибивает systemd намертво и навсегда. Даже elogind не шевелится. consolekit можно собрать без cgroups и он будет жить. Отключение namespaces убивает некоторую изоляцию. Вы не хотите настроить простую DAC, спорите о том, что можно выделять память одновременно в режиме для записи и изменения, вы действительно думаете что в этом случае вам поможет изоляция namespaces? > Ну тут даже не знаю, что сказать. Видимо, до таких высот мы еще не доросли, да. Но тогда не доросли и все остальные. Ибо почему то, о ужас, … Многие понимают, знают как и могут, но АНБ, ФСБ, *Б этого не надо. Чем меньше у вас безопасности тем им легче исполнять свои обязанности....
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (114), 26-Фев-20, 17:25
	- Вы не хотите настроить простую DAC, спорите о том, что можно выделять память одновременно в режиме для записи и изменения, вы действительно думаете что в этом случае вам поможет изоляция namespaces? + Вы не хотите настроить простую DAC, спорите о том, что можно выделять память одновременно в режиме для записи и исполнения, вы действительно думаете что в этом случае вам поможет изоляция namespaces? s/изменения/исполнения/
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Consta (?), 02-Мрт-20, 15:24
	>> Мы когда-то посовещались и Я так решил. Правильно понимаю, что предлагается в качестве доказательств рассматривать ссылки на комментарии в опеннете, а не на научные работы, выполненные корректно с точки зрения методологии? >> Отключение cgroups прибивает systemd намертво и навсегда >> Отключение namespaces убивает некоторую изоляцию. Да неужели? >> Да, GNU/Linux, но с расширенными возможностями ядра, компилятора, глибс и бинутилс. Какие тогда "расширенные возможности ядра" имелись ввиду? >> capabilities я выбрасывать нигде не говорил! Если их не выбрасывать, и они остаются, то как тогда учесть их наличие в формальной модели? Или это не предполагалось, а просто решили об этом деликатно умолчать? Я уже писал про то, что такая позиция, фактически, приводит к возникновению неописанных ФБО в ядре и проблеме НДВ\РДВ. >> Многие понимают, знают как и могут... Прекращайте демагогию. По существу тезиса о том, что и Red Hat и SUSE (плюс с ними IBM), и Ubuntu/Canonical совершенно аргументированно считают, что формализация моделей безопасности (особенно их при верификации) для Linux практически невозможна, есть что сказать? >> Вы не хотите настроить простую DAC, спорите.... Доброе утро. Я вообще не про это. Я про проблему формализации модели безопасности для Linux. Напоминаю, что именно с этого и начался диалог. Я не спорю, не предлагаю, я указываю на поток проблем, возникающих из необдуманного решения. Решение тупо формализовать модель на бумаге - ничего не дает с точки зрения ИБ. Ибо она или не учтет все возможные ФБО, или лишит ядро имеющегося там функционала. Плюс - чудовищная трудоемкость проверки реализации этой модели. Ну и про простоту DAC. А простого DAC в Linux и нету. Есть последовательное множество DAC - UNIX permission bits, POSIX ACL, capabilities плюс - в какой то степени cgroups и namespaces. В каком месте тут простота, если требуется описывать и уметь настраивать все это множество? Особенно, когда необходимо DAC применять комплексно? Сюда еще нужно добавить netfilter для полноты картины. Это тоже DAC, только для информационных потоков. А уж если SELinux появился - то это еще один механизм DAC, если без MLS, конечно.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	135. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (135), 04-Мрт-20, 16:24
	> ссылки на комментарии в опеннете, а не на научные работы Там вполне достаточно чтобы сложить 2+2. > Какие тогда "расширенные возможности ядра" имелись ввиду? Дополнения для безопасности. > Если их не выбрасывать, и они остаются, то как тогда учесть их наличие в формальной модели? Писал уже, capabilities учитываются как независимые от DAC и MAC. Точка применения: последовательно с Integrity, после него и паралельно DAC и MAC. > формализация моделей безопасности (особенно их при верификации) для Linux практически невозможна, есть что сказать? Тяжело, но можно. > Плюс - чудовищная трудоемкость проверки реализации этой модели. Вы пытаетесь построить одну большую мат модель. Я же говорю о многих маленьких, каждая с которых закрывает/решает свою проблему. Прочти посты выше. На бумаге мы оперируем уже моделями и следим чтобы они закрывали все теоретические дыры и решали все проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Consta (?), 06-Мрт-20, 11:12
	>> Там вполне достаточно чтобы сложить 2+2. Да я и не сомневался, что сразу все ясно. >> Дополнения для безопасности. Решение, безусловно, новаторское. Сначала надо вырвать с мясом из ядра те вещи, которые и так уже работают, поломав по дороге совместимость пользовательского окружения. А потом надо затолкать в ядро непонятно что. И обозвать это непонятное - "расширенными возможностями" и "дополнениями безопасности". Подход тоже ясен, да. >> Писал уже, capabilities учитываются как независимые от DAC и MAC. Это тоже прорыв. К сведению: capabilities - есть типичный DAC. Ибо это дискреционное разграничение доступа на основе атрибутов. Не считать capabilites механизмом DAC - это точно такое же гениальное решение, как и предыдущее. Кроме того, сам термин "учитываются" - вот он что означает? Как именно множество то капабилитей планировалось формализовать в модели и увязывать с другими механизмами DAC? Ау? Или не планировали все-же? Хотели как то "учесть"? А что такое - "учесть"? Посчитать, сколько их в конкретном ядре есть и написать какая для чего нужна? И все? Так для этого и писать то ничего не надо. Все в манах есть. Даже на русском языке. А формально доказывать, что они всегда корректно работают? Нет? Не надо делать? Ну и правильно. >> Тяжело, но можно. Это демагогия. Есть ли независимо подтверждаемые и научно обоснованные примеры? Их нет. Как уже справедливо писали выше - формальная модель в каком-то виде (не полном, ибо я то ее как раз читал, и не одну) есть для Astra линукс, но это мало что дало на практике. Мандатка там текла, да, тупо зная пароль пользователя и используя su можно было зафигачить эскалацию привилегий и инициировать факт НСД. Находясь в одном уровне, прямо и без затей из оболочки можно было запросить доступ к файлу на другом уровне. Не знаю, как там у них с этим делом сейчас. Закрыли эту дыру или нет. Зато была модель, да. Этот пример отлично иллюстрирует как раз корень проблемы - косая реализация "бумажной" формальной модели, неверифицированной и с плохим аудитом - привела к дыре в механизме безопасности. И во всех виденных мной моделях - есть грабли. Модели не полные. А значит реализация, таким образом, как минимум содержит неформализованные ФБО в ядре. А у ведущих разработчиков ОС Linux, коими в том числе являются Red Hat, SUSE и Canonical - моделей нет совсем. Они и не претендуют. Ибо они то как раз хорошо понимают чудовищность и объем проблемы. Кроме того, я уже предлагал - можно не соглашаться с моими доводами, я не заставляю. Можно не считать мою агрументацию убедительной, я не заставляю. Но есть факты, они упрямая вещь, а моя аргументация может быть независимо от меня проверена. Не согласны с аргументацией и фактами - ну попробуйте обратиться в какую-нибудь аккредитованую CCRA испытательную лабораторию. Их много. Можно обратиться к IBM, Red Hat, Suse, Canonical, написать хоть Таненбауму. И предложить им написать формальную модель или модели. Может, они что-то ответят? >> Вы пытаетесь построить одну большую мат модель. Вовсе нет. Я пытаюсь сказать, что количество моделей не имеет значения. Одна она, две, или двадцать две. Важно то, что модель или модели должны на формальном языке описывать все без исключения (еще раз повторю - все без исключения!) механизмы принятия решений, включая решения по разграничению информационных потоков тоже (то есть и фильтр пакетов тоже, если он есть, а в линуксе он есть, а сейчас и не один). Именно для этого модель(и) и нужна(ы). И кроме этого, модель(и) должна(ы) иметь непротиворечивое(ые), независимо проверяемое(ые) доказательство(а). Проще всего это сделать с помощью математики. Доказательство даст алгоритм. А алгоритм уже можно реализовать в коде. И проверить реализацию. А ну как в коде ошибка, и алгоритм реализован не верно? Если этого не сделать, то никакой реальной пользы не будет. >> На бумаге мы оперируем уже моделями и следим чтобы они закрывали все теоретические дыры Демагогия. Что такое - "теоретическая дыра"?  Модель (ну или совокупность моделей, если угодно, сути это не меняет) не призвана закрывать какие-то там дыры. Хоть "теоретические", хоть "практические". Доброе утро. Модель должна доказывать (и не только доказывать формальным способом, а и иметь как минимум еще ссылки на проверяемую реализацию) - что цели безопасности достижимы, угрозам безопасности можно успешно противодействовать, политики безопасности реализуемы, предположения безопасности выполнимы. А все эти угрозы, цели, политики и предположения уже давным-давно сформулированы, определены и заданы заранее. И у нас и у них. Смотрим любой профиль защиты - и там (о ужас!) их находим. Как для самой ОС, так и для среды её выполнения. Так что никаких "теоретических дыр" нет. Есть вполне конкретные, четко сформулированные цели безопасности, которых нужно достичь, угрозы, которым нужно противостоять и т.д. Зачем вы пишите про "теоретические дыры", которых нет в природе? Просто почитайте уже хотя бы любой профиль защиты и постарайтесь понять, что там написано, и почему именно так написано. Подытожим: а) некие люди пришли в Газпром и предложили (создать?) некую реализацию ОС на базе Линукс, содержащую некие "расширенные возможности ядра", задекларированные как "дополнения для безопасности"; б) те же лица предложили (создать?) еще некую документацию на систему. Как минимум - формальную модель безопасности; в) при всем этом - в модели не предполагалось приводить описание и формализацию cgroups, namespaces и capabilities, и, похоже, netfilter тоже. Все это, конечно, привело бы к возникновению проблемы НДВ\РДВ и потенциальному обходу описанных и формализованных в модели механизмов безопасности. Но кому оно надо? Зачем бумагу и время тратить, и что-то там описывать и формализовывать, правда?; г) при всем этом, на сколько я понял, реализация предполагала отключение cgroups и namespaces, что привело бы к заметной деградации в юзерспейсе. Вместо них в реализацию должны были бы быть включены некие магичесикие и никак по переписке не идентифицируемые "расширенные возможности ядра", задекларированные как "дополнения для безопасности". Что это - не ясно. Что это дает, кроме поломок в юзерспейсе - не ясно; д) проверка реализации не предполагала аудита кода, но, странным образом, предполагала его верификацию. Цитата: "Аудит всего кода не предполагался. Вот изменяемой, для дачи гарантий, часть кода предполагалось верифицировать с формальной мат моделью". Верификация - это не просто аудит. Это проверка доказательств правоты, помимо просто аудита. Ну да ладно. Про чудовищные объемы аудита и верификации, а также осуществление прослеживания (алгоритм -> структура данных -> конкретная функция в ядре -> системный вызов, взаимодействующий с функцией -> прикладная программа) - писать и повторяться не буду, писал ранее.  Если не проверить и не проследить все, что в скобках в предыдущем предложении - имеем неясно что, с точки зрения ИБ. Очевидно, что это все и не планировалось. Опыт Red Hat, SUSE и Canonical был проигнорирован. В целом, мне все ясно. Тут налицо какая-то мутная попытка выдать непонятно что за защищенную систему. Хорошо, что такое не получилось. За сим более писать не буду. И так все понял. И про уровень экспертизы, и про модель, и про реализацию системы.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	147. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (147), 07-Мрт-20, 12:40
	Нет времени спорить и что то доказывать. Это сложные вещи. Кратко: Сетевой экран, как в DAC таки и  MAC включал. > К сведению: capabilities - есть типичный DAC. Ибо это дискреционное разграничение доступа на основе атрибутов. Не считать capabilites механизмом DAC - это точно такое же гениальное решение, как и предыдущее. Да я лично capabilites механизмом DAC не считаю! Повторю еще раз сказание мною выше: DAC - да дискретный, как много чего другого. Но DAC дискретный по пользователям, а capabilites дискретный по привилегиям суперпользователя. Это разные вещи по точке их применения!!! DAC применяется последовательно, после Integrity и перед MAC. А capabilites применяются паралельно DAC и MAC, можно считать почти незавтсимо от них. Grsecurity контролирует capabilites в RSBAC и/или в независимой от DAC и MAC реализации изоляции процессов. Перед постройкой мат модели должно быть понимание в какой последовательности по отношению друг к другу применяются разные модели безопасности. Capabilites сработает и при обработки DAC и при обработки MAC, оно работает паралельно им и можно считать независимо.
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	23. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от pin (??), 16-Фев-20, 13:42
	Теперь это Астра?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	33. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Michael Shigorin (ok), 16-Фев-20, 18:27
	> Теперь это Астра? Если вдруг Вы угадали -- то было бы особенно пикантно, потому как несколько лет назад тамошнюю мандатку обходили с помощью su(1).  Причём знакомый, который с этим вынужден был мучаться, упоминал, что от этой информации поставщик ещё и отбрыкивался, помнится...
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (68), 18-Фев-20, 09:01
	Нет не Астра.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	24. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+3 +/–
	Сообщение от cutlass (?), 16-Фев-20, 14:59
	Спектре матмодель учитывала?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	71. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (68), 18-Фев-20, 09:02
	Это было 10 лет назад.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+2 +/–
	Сообщение от Аноним (27), 16-Фев-20, 16:23
	На ентерпрайз-дистрибутивах можно неплохо попилить, а на твоей разработке как?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	31. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Michael Shigorin (ok), 16-Фев-20, 18:24
	> Вернемся к истокам и вспомним историю первого безопасного дистрибутива Linux > - Adamantics Во-первых, если он и претендовал на "первый безопасный", это была ложь. Во-вторых, Adamantix 1.0 был выпущен в 2003 году, а практически применявшаяся бета ALT Linux Castle с RSBAC -- ещё в 2001: http://www.linuxcenter.ru/lib/articles/distrib/altlinux/cast... > В РФ есть проблема образования - ИТ безграмотность. Её демонстрацию вовсе не обязательно было ещё и матом сопровождать.  Почитайте здесь комментарии solardiz (который, в отличие от Вас, известен на публике _практической_ грамотностью в виде кода) -- вдруг дойдёт, что место Вашей матмодели -- среди проектов вечных двигателей, включая и мой школьный. PS: а если ещё и не Вашей лично, а девянинской (ср. #23) -- тогда тем более.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	36. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от tensor (?), 16-Фев-20, 19:57
	Всё уже придумано полвека назад, но только не бздунами под дырявую платформу: https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualizat... А основная проблема amd64 даже не в дырявости, а в том, что без хаков с vmx и "защитой страниц" поп-вирт будет работать как старенький атом.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	59. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Аноним (-), 17-Фев-20, 17:00
	> которая даст гарантии не зависимо от любых действий пользователя они понять > пока не могут, а поверить уже не хотят. Да, в донкихотство теперь не верит даже Газпром, им видимо донесли что бюджет все же не резиновый. ОС общего назначения таким макаром не получится, а узкоспециализированное нечто - слишком нишевое.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	72. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (68), 18-Фев-20, 09:10
	Речь шла об ОС общего назначения.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Аноним (81), 19-Фев-20, 01:00
	> Речь шла об ОС общего назначения. В ос общего назначения крапа слишком уж много, все предусмотреть имхо малореально. Ну и вон там с 2010 года примерно на интелском железе ME в каждой дырке, всегда активный, dma-capable, с мутной фирмварью делающей неизвестно что? Как его такой моделировать то, кроме FATAL VULN, unless proven otherwise?
	Ответить | Правка | Наверх | Cообщить модератору

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

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