The OpenNET Project / Index page

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



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

"Удалённая уязимость в ядре NetBSD, эксплуатируемая из локальной сети"  +/
Сообщение от opennews (??), 14-Окт-20, 11:44 
В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке jumbo-пакетов в драйверах для сетевых адаптеров, подключаемых по USB. Проблема приводит к копированию части пакета за пределы буфера, выделенного в кластере mbuf, что потенциально может использоваться для выполнения кода атакующего на уровне ядра через отправку определённых кадров из локальной сети. Исправление для блокирования уязвимости внесено 28 августа, но сведения о проблеме раскрыты только сейчас. Проблема затрагивает драйверы atu, axe, axen, otus, run и  ure...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53888

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

Оглавление

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


1. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +9 +/
Сообщение от Аноним (1), 14-Окт-20, 11:44 
Exploitable-over-net-BSD
Ответить | Правка | Наверх | Cообщить модератору

54. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –3 +/
Сообщение от VINRARUS (ok), 14-Окт-20, 18:39 
Ну отключи NetBSD от Net
Ответить | Правка | Наверх | Cообщить модератору

81. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от www2 (??), 15-Окт-20, 07:34 
От USB-адаптера Ethernet. Саму по себе NetBSD можно встретить довольно редко, а уж системы с NetBSD и такими сетевыми картами вообще, наверное, по пальцам пересчитать можно. Почему-то представился гик-хипстер, установивший NetBSD на Macbook, который при этом предпочитает не пользоваться WiFi.
Ответить | Правка | Наверх | Cообщить модератору

3. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +17 +/
Сообщение от little Bobby tables (?), 14-Окт-20, 11:47 
правильно объединили новости : бсд и венда
Ответить | Правка | Наверх | Cообщить модератору

34. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +5 +/
Сообщение от Аноним (-), 14-Окт-20, 13:50 
> правильно объединили новости : бсд и венда

Ну да, хоть в новостях будет единение, WSB им-то не светит!

Правильно добавили в список ссылок ниже, первым пунктом:
OpenNews: Удалённая уязвимость в systemd-networkd

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

46. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –5 +/
Сообщение от Аноним (46), 14-Окт-20, 15:08 
Если WSL - это немного оптимизированная виртуалка с линуксом - то WSB существует уже давно.
Ответить | Правка | Наверх | Cообщить модератору

80. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –6 +/
Сообщение от Аноним (80), 15-Окт-20, 07:32 
Ваш Вайн это виртуалка, а wsl это интерпретатор. Двуличные сектанты-представители свободки
Ответить | Правка | Наверх | Cообщить модератору

96. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от daemontux (?), 15-Окт-20, 09:25 
А кого wsl интерпретирует?
Ответить | Правка | Наверх | Cообщить модератору

98. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –2 +/
Сообщение от Аноним (80), 15-Окт-20, 09:40 
В Гугле забанили? Понимаю
https://ru.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux
Ответить | Правка | Наверх | Cообщить модератору

4. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от A.Stahl (ok), 14-Окт-20, 11:47 
>jumbo-пакетов

Это, вроде, называется jumbo frame. Кадр. По аналогии с Ethernet кадрами. По ссылке "packet", но мне кажется это опечатка.

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

6. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от Аноним (6), 14-Окт-20, 12:02 
>>Unfortunately, there are some security risks related to ICMPv6 RA messages. On networks that do not yet use IPv6, the dual-stack hosts sit dormant waiting for an eventual RA message to awaken their IPv6 connectivity.  An attacker can craft a “rogue RA” message on these networks, get the dual-protocol nodes on the network to configure their IPv6 addresses and utilize the attacker’s system as their default gateway.

Оно дырявое by design. Это первое о чём я подумал когда увидел фразу "передачи конфигурации DNS через пакеты ICMPv6" Что они ожидали?

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

41. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +5 +/
Сообщение от Онаним (?), 14-Окт-20, 14:03 
Вся автоконфигурация в v6 - одна большая сплошная дыра.
Ответить | Правка | Наверх | Cообщить модератору

42. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Онаним (?), 14-Окт-20, 14:05 
Упреждая вопли про DHCP в v4, сразу же:
В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.
Плюс надо не забыть отключить линк-локал, шлак и приём RA.
Ответить | Правка | Наверх | Cообщить модератору

44. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от пох. (?), 14-Окт-20, 14:11 
> В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.

by design, угу. Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы), и тебе никогда в жизни не придется запоминать и безошибочно набирать эту бредятину (по-моему, разработчики были из неосиляторов v4, и реально думали, что все кругом испытывают те же трудности) - правда, как обычно, на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?

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

62. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (62), 14-Окт-20, 19:42 
Всё потому что тебя там не было.
Ответить | Правка | Наверх | Cообщить модератору

70. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним (70), 14-Окт-20, 22:10 
Его, не его, но судя по количеству глупостей в протоколе и по триумфальному внедрению IPv6 там крайне не хватало практикующих сетевых инженеров.
Ответить | Правка | Наверх | Cообщить модератору

83. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от www2 (??), 15-Окт-20, 07:48 
Не надо переоценивать умственные способности большинства практикующих сетевых инженеров.

Практикующий сетевой инженер лучше сделает приватную сеть из 10.0.0.0/8, 192.168.0.0/16, 172.12.0.0/12, 169.254.0.0/16 и завернёт всё это за NAT, а потом будет героически сражаться с нехваткой свободных портов на NAT, множить сначала IP-адреса на одном узле, потом множить узлы NAT, потом решать проблемы с балансировкой трафика между этими NAT-узлами, потом придумывать, как ФСБ-шникам отвечать на запросы, с какого IP-адреса определённый абонент в определённое время выходил в интернет и ему ли принадлежит трафик с определённого порта.

Как говорится, мне некогда точить пилу, мне нужно пилить.

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

93. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от 1 (??), 15-Окт-20, 09:05 
эт точно !
Ответить | Правка | Наверх | Cообщить модератору

97. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от daemontux (?), 15-Окт-20, 09:29 
Сразу видно что  большими сетями вы не занимались...
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

82. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от www2 (??), 15-Окт-20, 07:43 
>Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы)

Мьсе из тех, кто ARP-, FDB-таблицы и таблицы маршрутизации на каждом сетевом узле заполняет вручную? DHCP, LLDP, VGRP, VTP, BGP, OSPF, RIP никогда не пользуется? RA из той же оперы, если что.

>на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?

DHCP не нужен, если устройству достаточно получить IPv6-префикс и узнать IPv6-адрес маршрутизатора. Мне коммутаторы попадались, на которых DNS-серверы в принципе некуда указать. Вот таким устройствам этого достаточно.

Всё остальное отдано наоткуп DHCPv6, где можно и адреса DNS-, NTP- и даже TFTP-серверов раздавать или там статические маршруты. Вполне разумно, я считаю.

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

78. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним 80_уровня (ok), 15-Окт-20, 02:55 
> руками конфигурировать те же v6 адреса - ад адешный

Чоита?

iface eth0 inet6 static
    address 2a0x:xxxx:xx:xxx:x::2/64
    gateway 2a0x:xxxx:xx:xxx:x::1

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

85. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 15-Окт-20, 07:52 
> Чоита?
> iface eth0 inet6 static
>     address 2a0x:xxxx:xx:xxx:x::2/64
>     gateway 2a0x:xxxx:xx:xxx:x::1

Сконфигурируй мне v6 без DHCP на PPPoE, который может подключаться к концентраторам, на которых разные подсети.

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

86. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 15-Окт-20, 07:53 
Без link-local и без RA с шлаком.
Я тебе сразу отвечу: не получится.
Потому что в PPP эти мажоры от академиков механизма конфигурации не-link-local вообще не предусмотрели.
За что могут гореть в аду.
Ответить | Правка | Наверх | Cообщить модератору

87. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 15-Окт-20, 07:55 
Ну и угу, потом если у тебя приём RA при этом не отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно ложится.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

107. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним 80_уровня (ok), 15-Окт-20, 13:30 
> Ну и угу, потом если у тебя приём RA при этом не
> отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно
> ложится.

Не отключал (в явном виде). Не ложится.

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

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

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

141. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от t28 (?), 17-Окт-20, 08:52 
Да это нeoсилятoр обыкновенный, что с него взять…
Не осилил обыкновенный IPv6, предоставляющий кучу инструментария для конфигурения.
А если сему джентльмену понадобится отконфигурить A2EA (ISO)? Или, скажем, X.121?
Представляю себе количество воплей.
Ответить | Правка | Наверх | Cообщить модератору

7. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от Аноним (7), 14-Окт-20, 12:18 
> приводит к копированию части пакета за пределы буфера

*facepalm*
даже комментировать не хочется... а то сразу набегут сами знаете кто

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

11. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –4 +/
Сообщение от Аноним (11), 14-Окт-20, 12:38 
Прокоментируй как будешь писать драйвер без unsafe кода, я подожду.
Ответить | Правка | Наверх | Cообщить модератору

25. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Lex (??), 14-Окт-20, 13:12 
Прокомментируй, как будешь писать драйвер, работающий с сетью, начисто забив на проверку длины и выход за границы, я подожду.
Хотя, зачем твой коммент ? Тут бы коммент автора, который УЖЕ написал тот драйвер.
Ответить | Правка | Наверх | Cообщить модератору

15. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (11), 14-Окт-20, 12:51 
> Stack smashing protection     No
> Forward-edge control flow protection     No
> Backward-edge control flow protection (e.g., shadow and safe stack)     No

даже комментировать не хочется... а то сразу набегут сами знаете кто (растовики со смузи доказывать что вы фсё фрёте)

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

18. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от Аноним (11), 14-Окт-20, 12:53 
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...

Совсем нет переполнений, угу :^)

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

8. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от FractaL (?), 14-Окт-20, 12:28 
> отсутствием проверки границ буфера при обработке jumbo-кадров

Ну в принципе любой может ошибиться, от языка это не зависит. На любом языке можно внести дыру безопасности.

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

14. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –3 +/
Сообщение от zshfan (ok), 14-Окт-20, 12:51 
На любом языке кроме языка Ада
Ответить | Правка | Наверх | Cообщить модератору

20. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (20), 14-Окт-20, 12:57 
А в Аде совсем нет возможности перейти к работе напрямую с адресами памяти?
Ответить | Правка | Наверх | Cообщить модератору

28. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –2 +/
Сообщение от Lex (??), 14-Окт-20, 13:16 
Конечно. А ещё там - парсеры, способные абсолютно безошибочно разбирать мусор любого, даже заранее неизвестного формата( включая битый ), приходящий от сторонних источников. Ну это, если верить анонам, именующим его нереально-безопасным( аноны, правда, и про рубин_на_рельсах и про его невероятную скорость и удобство  что-то говорили, но.. какой с анонов спрос ? )
Ответить | Правка | Наверх | Cообщить модератору

31. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Окт-20, 13:24 
>> кроме языка Ада
> в Аде совсем нет возможности

Там аватарка намекает, что вы о разных языках ...

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

33. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от zshfan (ok), 14-Окт-20, 13:36 
Нет, мы об одном и том-же языке. Ада насколько мне хватает моих знаний гораздо безопаснее плюсов и всяческой кофейной гущи.
Ответить | Правка | Наверх | Cообщить модератору

48. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним (48), 14-Окт-20, 16:29 
>> насколько мне хватает моих знаний

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

Эрудит,мля :)

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

40. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от nomad__email (ok), 14-Окт-20, 14:02 
Ada не устраняет человеческий фактор. Софт Ariane-5, между прочим, на ней был написан
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

71. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (70), 14-Окт-20, 22:11 
Это другое™
Ответить | Правка | Наверх | Cообщить модератору

53. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (53), 14-Окт-20, 17:41 
Верно
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

56. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от VINRARUS (ok), 14-Окт-20, 18:46 
>На любом языке можно внести дыру безопасности.

Даже на языке жестов?

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

84. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от www2 (??), 15-Окт-20, 07:51 
На нём особенно. В разных культурах одни и те же жесты имеют совершенно разный смысл. Лучше никогда не используйте за границей привычные вам жесты, если вы на 100% не уверены в их значении для местного населения.
Ответить | Правка | Наверх | Cообщить модератору

89. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (89), 15-Окт-20, 08:27 
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке

Уважаемый FractaL, NetBSD это вам не GNU/Linux, хоть и написан на C. Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.

Почему переполнение буфера, в ядре NetBSD написанном на C и прогах написанных на C, запущенных на ядре NetBSD, работать не будет?

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

100. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 15-Окт-20, 10:16 
Так почему же, интересно? Какая-то защита, сборка с флагами или что?
Ответить | Правка | Наверх | Cообщить модератору

113. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –2 +/
Сообщение от Аноним (113), 16-Окт-20, 09:14 
Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112
Ответить | Правка | Наверх | Cообщить модератору

120. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Consta (?), 16-Окт-20, 14:50 
DAC от атак, связанных с переполнением буфера не помогает. К тому же неясно, что иненно уникального в DAC netbsd. Ну как у всех же её DAC.
Ответить | Правка | Наверх | Cообщить модератору

125. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (125), 16-Окт-20, 17:10 
W^X и NX инструкции процессора расширяют DAC на страници оперативной памяти. Ядро NetBSD имеет поддержку W^X как для ядра, так и для всех процессов. W^X это DAC просто права выставляются не файловой системой для файла, а ядром и процессором для страниц оперативной памяти.
Ответить | Правка | Наверх | Cообщить модератору

123. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 16:24 
> Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112

Хватит уже тиражировать свою чушь про DAC. То, на что ты сослался далее (https://www.opennet.ru/opennews/art.shtml?num=50763) не имеет никакого отношения к тому, о чём речь сейчас.

И в ядре netbsd и в ядре openbsd реализован W^X для _ядра_ (в netbsd, ЕМНИП, появилось раньше, чем в openbsd) и именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.

То, что описано в "Планах по усилению механизма защиты W^X в OpenBSD", на который ты почему-то ссылаешься - это про юзерспейс. То есть, на текущие уязвимости никакого влияния не оказывает. И, если что, решение "не форсить W^X pt 2" было принято сильно раньше того, что описывается в той новости. Хотя, кому надо, может и зафорсить средствами pledge.

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

124. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (125), 16-Окт-20, 17:05 
> именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.

Об этом и речь,что уязвимости нет. Падение ядра будет.

W^X это от DAC просто область применение не файл на диске, а страницы оперативной памяти и реализация в ядре OS необходима дополнительная. А по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.

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

127. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 17:49 
> по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.

Чего?
DAC = discretionary access control? Или ты имеешь ввиду что-то другое?

https://security.stackexchange.com/questions/63518/mac-vs-da... - мне сложно что-то добавить к тому, что здесь написано про DAC.

Т.е. в рамках модели DAC любой пользователь может определить какие права будут иметь другие пользователи на действия с его файлами + рут, который нарушает DAC и может всё. При чём тут W^X / W|X вообще?

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

131. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –2 +/
Сообщение от Аноним (125), 16-Окт-20, 18:25 
Да, DAC это именно Дискретный Контроль Доступа. Минимальная дискретность раздачи прав - пользователь.

Да драйвера файловой системы и сама OS реализует DAC через установку прав на файлы RWX.

Но, ядро OS может и безопасное ядро OS должно, устанавливать права RWX и на страници оперативной памяти. W^X это DAC но реализован для страниц оперативной памяти.

Ядро безопасной OS должно разделять процессы по пользователям которые их запустили. Вася не должен видеть процессы Вовы. В Linux это делает yama или патчи grsecurity. И это тоже DAC по пользователям просто объектами есть процессы в оперативке, а не файлы на диске.

Когда я говорю создавать разные разделы /, /home, /tmp, /var и строго соблюдать принцип DAC: W^X то имею ввиду опции монтирования:
/ exec,ro
/home noexec,rw
/tmp noexec,rw
/var noexec,rw

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

132. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 18:33 
DAC - это _модель_ безопасности, т.е. с правами фс или исполняемостью памяти напрямую никак не связано.

Прочий поток сознания комментировать не намерен, и так всё понятно.

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

134. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (134), 16-Окт-20, 19:16 
Я реализацию W^X ядром в отношении страниц памяти, а также YAMA в отношении процессов отношу к модели безопасности DAC.

https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Модель DAC не ограничивается файлами на диске, она также касается процессов и страниц/сегментов оперативной памяти.

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

136. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 19:38 
Я уже не вижу смысла спрашивать, способен ли ты прочитать и осознать то, что я тебе пишу и на что ссылаюь, очевидно, что нет. Но понимаешь ли ты, что то, что ты сейчас написал и скинул всё также ни к селу ни к городу?

Что ты там к чему относишь - вообще абсолютно безразлично. По _определению_ DAC - это модель безопасности, когда условный пользователь _сам_ определяет доступ для других условных пользователей права доступа для принадлежащих ему объектов. Например: доступ к файлам пользователя в unix'ах или доступ к фоткам/записям/etc пользователя в соцсетях - и там и там пользователь _сам_ определяет, у кого есть права, у кого нет. И какие права.

Возвращаясь к _принудительному_ W^X - в каком месте тут DAC? Ты когда-то прочитал клёвую аббревиатуру и теперь таким образом хочешь показать, что ты прошаренный? Получается пока, увы, иначе.

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

149. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Consta (?), 18-Окт-20, 10:41 
Камрад, не трать время. Тут персонажа надо к врачу отправлять сразу. Можно было было многое спросить. Например, сможет ли он привести принципиальную матмодель дискреционного монитора обращений или нет. Или является ли NPF реализацией DAC? Но бесполезно...  
Ответить | Правка | Наверх | Cообщить модератору

135. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (134), 16-Окт-20, 19:23 
Реализация DAC связана и с файлами ис памятью:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Мы говорим о разной реализации DAC в разных OS. Где то она полная, где то ограничения.

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

143. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Карабьян (?), 17-Окт-20, 15:40 
Как грамотно сделать корень ро?
Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

139. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok), 17-Окт-20, 00:59 
Как бээсдэшник со стажем скажу просто: вы обделались.
Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

9. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от notcurver (?), 14-Окт-20, 12:34 
Со всеми бывает.
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  +4 +/
Сообщение от Аноним (46), 14-Окт-20, 12:35 
Ответить | Правка | Наверх | Cообщить модератору

12. Скрыто модератором  +/
Сообщение от Аноним (12), 14-Окт-20, 12:42 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  –2 +/
Сообщение от A.Stahl (ok), 14-Окт-20, 12:45 
Ответить | Правка | Наверх | Cообщить модератору

16. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 14-Окт-20, 12:52 
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. Скрыто модератором  +/
Сообщение от zshfan (ok), 14-Окт-20, 12:54 
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

22. Скрыто модератором  +/
Сообщение от Аноним (22), 14-Окт-20, 12:59 
Ответить | Правка | Наверх | Cообщить модератору

26. Скрыто модератором  +/
Сообщение от A.Stahl (ok), 14-Окт-20, 13:14 
Ответить | Правка | Наверх | Cообщить модератору

29. Скрыто модератором  –1 +/
Сообщение от Lex (??), 14-Окт-20, 13:19 
Ответить | Правка | Наверх | Cообщить модератору

32. Скрыто модератором  +/
Сообщение от A.Stahl (ok), 14-Окт-20, 13:31 
Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором  +/
Сообщение от Аноним (-), 14-Окт-20, 13:14 
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

24. Скрыто модератором  +1 +/
Сообщение от Анонас (?), 14-Окт-20, 13:03 
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

30. Скрыто модератором  +/
Сообщение от Аноним (-), 14-Окт-20, 13:20 
Ответить | Правка | Наверх | Cообщить модератору

17. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Дон Ягон (ok), 14-Окт-20, 12:52 
Звучит эпично, но по факту - так себе. Ну в смысле что локальная сеть + usb-свистки - не слишком высокий шанс на реальную эксплуатацию.

А вот объединение с новостью про винду позабавило.

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

21. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 14-Окт-20, 12:59 
Почему? Известно же где они код берут, вроде и не секрет.
Ответить | Правка | Наверх | Cообщить модератору

63. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (62), 14-Окт-20, 20:07 
> локальная сеть + usb-свистки

raspberry pi

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

23. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (6), 14-Окт-20, 13:01 
Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а не уязвимостью Васян-драйвера?
Ответить | Правка | Наверх | Cообщить модератору

35. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 14-Окт-20, 13:52 
Откуда взялись драйвера можно посмотреть в man'ах, всё как обычно. Драйвера, перечисленные в новости были портированны разработчиками netbsd из openbsd и один драйвер из freebsd. Портированы достаточно давно, т.е. не вчера. Например, axe появился в netbsd 3.0, а otus - в netbsd 6.

Про наличие аналогичных уязвимостей в open/free bsd мне ничего не известно.

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

74. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 14-Окт-20, 23:34 
> Про наличие аналогичных уязвимостей в open/free bsd мне ничего не известно.

"
revision 1.59
date: 2017/07/20 22:29:26;  author: stsp;  state: Exp;  lines: +6 -1;  commitid: GrlKQv8bl2DbBLNp;
Make otus(4) drop frames larger than MCLBYTES.
Problem reported by Ilja Van Sprundel.
ok deraadt@ tb@
"

По меньшей мере в одном драйвере дыра была и в openbsd, без понятия пока, правда, что там насчёт разрушительности последствий (но, подозреваю, что примерно то же самое).
Правда, пофикшено в 2017 году. Баги нашёл один и тот же человек, к слову.

Пойду-ка попробую и остальные diff'ы найти-почитать да с оригиналом сравнить. Жаль нетбсдшники не публикуют патчи в секьюрити-анонсах (ну или я в глаза сношаюсь), как опенбсдшники, было бы чуть удобнее.

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

75. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 14-Окт-20, 23:50 
> Баги нашёл один и тот же человек, к слову.
> Ilja Van Sprundel

Он, кстати, норм так набрасывать умеет: https://www.csoonline.com/article/3250653/is-the-bsd-os-dyin...

А заголовки в статье так вообще желтушные: "NetBSD the "clear loser" in terms of code quality". Тро-ло-ло.

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

110. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (110), 15-Окт-20, 19:51 
Это диверсия со стороны OpenBSD! Чтобы стать более безопасной нужно сделать другие ОС менее безопасными.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

38. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –3 +/
Сообщение от Аноним (-), 14-Окт-20, 13:59 
> Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а
> не уязвимостью Васян-драйвера?

Да все просто!
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-...
> Some USB network interface drivers are missing a bounds check
> The following drivers were audited and do not appear to be affected in

netbsd-9:

Если драйвер для BSD - значит уязвимость в БСД, ведь там одни неосиляторы и неудачники (мы все так говорим, а значит это правда!)
А вот если бы драйвер был для Пингвинчика, то пришлось бы разбираться, почему очередной Васян налажал!

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

36. Скрыто модератором  +/
Сообщение от Онаним (?), 14-Окт-20, 13:57 
Ответить | Правка | Наверх | Cообщить модератору

37. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от КО (?), 14-Окт-20, 13:58 
"начиная с обновления 1709"
как знал что говнокодят
Ответить | Правка | Наверх | Cообщить модератору

39. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Онаним (?), 14-Окт-20, 14:01 
Радует, что с привычкой на винде и не только отключать IPv6 сразу же после развёртывания системы (а то и вместе с развёртыванием) это не особо страшно :) IPv6 одна большая сплошная дыра в целом, начиная с лёгкой возможности захламления neighbor-таблиц.
Ответить | Правка | Наверх | Cообщить модератору

45. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от пох. (?), 14-Окт-20, 14:13 
Хаха - я вот был немного удивлен, узнав какой танец-с-граблями надо исполнять в современном редхламе, чтобы отключить совсем и навсегда. Полагаю, в следующей версии уже не будет отключаться вообще (а там и винда подтянется)
Ответить | Правка | Наверх | Cообщить модератору

59. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 14-Окт-20, 19:26 
Да ладно, какой там танец с граблями.
Две строчки в sysctl. Или один параметр в параметры ядра.
Ответить | Правка | Наверх | Cообщить модератору

60. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 14-Окт-20, 19:27 
Параметр - ipv6.disable=1
sysctl - net.ipv6.conf.all.disable_ipv6=1 , net.ipv6.conf.default.disable_ipv6=1
Ответить | Правка | Наверх | Cообщить модератору

72. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от онанимуз (?), 14-Окт-20, 22:28 
к сожалению, это не работает.
система игнорирует эти настройки и всё равно поднимает ипв6, если встречает что-нибудь про него в каком-либо из других конфигов, как минимум это /etc/hosts и /etc/ssh/sshd_config.
все конфиги не помню, записаны где-то в мануале "как отключить это сраное дерьмо говна v6" на рабочем компе.
Ответить | Правка | Наверх | Cообщить модератору

88. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 15-Окт-20, 07:55 
С sysctl может быть беда, если кто-то перепишет /proc/...
Опция ядра работает железно.
Ответить | Правка | Наверх | Cообщить модератору

61. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Онаним (?), 14-Окт-20, 19:31 
У нас немножко другой коленкор, у нас инфраструктурные системы кастомизированы, и по умолчанию интегрирован systemd-networkd, там две строчки в .conf-файле на интерфейсах.

LinkLocalAddressing=no
IPv6AcceptRA=no

Первое заодно фигачит 169.254.x.x, который в других случаях надо через /etc/sysconfig/network параметро NOZEROCONF=yes выключать.

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

94. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от 1 (??), 15-Окт-20, 09:11 
Тебя ждёт неожиданность, так как Exchange не устанавливается без IPv6
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

95. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Онаним (?), 15-Окт-20, 09:12 
Наш виндоадмин спокойно гоняет Exchange без IPv6 уже лет эннадцать.
Ответить | Правка | Наверх | Cообщить модератору

102. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от 1 (??), 15-Окт-20, 11:29 
Мда ... люди теряют навыки чтения (или понимания того, что написано).

Сходи в словарь и найди различия между словами "устанавливается" и "работает"

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

111. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Онаним (?), 15-Окт-20, 20:38 
Ещё раз: нашему виндоадмину это фиолетово :)
Не знаю, может он включал v6, делал major update, и потом выключал, но в любом случае это прошло быстро и незаметно.
Ответить | Правка | Наверх | Cообщить модератору

47. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (47), 14-Окт-20, 16:07 
Ничего идеального в мире it нет и не будет, дыры есть были и будут. Всё расходимся.
Ответить | Правка | Наверх | Cообщить модератору

49. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (49), 14-Окт-20, 16:39 
>Уязвимость проявляется начиная с обновления 1709 для Windows 10

"СЕМЁРКА НЕБЕЗОПАСНА, ПЕРЕХОДИТЕ НА 10КУ!" - говорили некоторые.

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

50. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (100), 14-Окт-20, 17:03 
От наличия уязвимости в десятке, семёрка безопаснее не станет. Десятку исправят, в отличие от.
Ответить | Правка | Наверх | Cообщить модератору

52. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (52), 14-Окт-20, 17:30 
Микромягкие прогнулись и продлили до 2023 года поддержку семерки.
Так что можешь откатиться)
Ответить | Правка | Наверх | Cообщить модератору

65. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от ННН (?), 14-Окт-20, 20:21 
Прогнулись, получая за это деньги.
Ответить | Правка | Наверх | Cообщить модератору

57. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от VINRARUS (ok), 14-Окт-20, 18:50 
Зато ХР стаёт безопаснее 10 с каждым обновлением 10.
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

77. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от СеменСеменыч777 (?), 15-Окт-20, 02:53 
ни одного (неофициального) аудита кода ХР еще не было.
Ответить | Правка | Наверх | Cообщить модератору

79. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от VINRARUS (ok), 15-Окт-20, 06:47 
> ни одного (неофициального) аудита кода ХР еще не было.

Ну код приоткрыли же :D

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

92. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 15-Окт-20, 08:48 
Путин пользуется икспи, по телевизору показывали. Вроде бы икспи единственная сертифицированная (ну просто там следящих компонентов ещё не было.)
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

99. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним (99), 15-Окт-20, 09:51 
A что не Роса с Эльбрусом?
Ответить | Правка | Наверх | Cообщить модератору

142. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от СеменСеменыч777 (?), 17-Окт-20, 14:59 
> Путин пользуется икспи

это были понты.
обои дефолтные => система свежепоставленая => никто ей не пользовался.

думю что "Путин" использует секретарей-референтов.

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

144. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 17-Окт-20, 16:21 
Полагаешь, он как и прошлый президент, эплофанбой?
Ответить | Правка | Наверх | Cообщить модератору

146. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:28 
> Полагаешь, он как и прошлый президент, эплофанбой?

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

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

145. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 17-Окт-20, 16:23 
Ну а дефолтные обои и не засранный рабочий стол это нормально, ты же не удивляешь когда кто-то годами использует только "безмятежность" или новую форточку в качестве обоев. Во всяком случае я всегда так делал.
Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

147. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:32 
> Ну а дефолтные обои и не засранный рабочий стол это нормально,

1) на дефолтных обоях плохо видны ссылки.
2) если в винде активно работать с документами, то р.стол неизбежно загаживается часто используемыми документами и ссылками для быстрого доступа.

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

148. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 17-Окт-20, 18:08 
Для быстрого доступа есть каталог с файлами быстрого доступа и панель со ссылками в локации на диске для быстрого доступа к каталогам. Нет ничего более отвратительного, чем засранный документами десктоп -- многое говорит о хозяине. И нет, нормально видно, там всякие тени и разноцветные затенения придумали, а я обои ставлю не для того чтобы на их фоне подписи значков рассматривать.
Ответить | Правка | Наверх | Cообщить модератору

151. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от СеменСеменыч777 (?), 18-Окт-20, 12:24 
> каталог с файлами быстрого доступа и панель со ссылками

это одно лишнее движение мышью + один лишний клик.

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

152. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (21), 18-Окт-20, 12:51 
>> каталог с файлами быстрого доступа и панель со ссылками
> это одно лишнее движение мышью + один лишний клик.

Только на рабочем столе мало места и с сортировкой и поиском проблемы. Как и с менеджментом.

https://www.youtube.com/watch?v=eEdiC-W4L7c

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

58. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (58), 14-Окт-20, 18:52 
а вот переписали бы на Rust и таких проблем не было бы
Ответить | Правка | Наверх | Cообщить модератору

64. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +2 +/
Сообщение от Аноним (62), 14-Окт-20, 20:11 
На lua.
Ответить | Правка | Наверх | Cообщить модератору

76. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от анонимуслинус (?), 15-Окт-20, 02:42 
так перепиши. я вообще хотел бы глянуть как перепишется любая ось на расте без unsafe))) раст же безопасный. так покажите плюсовикам и прочим как он крут. особенно ядрышко системы и драйвера))))
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

91. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (89), 15-Окт-20, 08:41 
Смотри A2, blue botle - не на C, без проблем и безопасно.

И с безопасностью C нет никаких проблем: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#90

Проблему с C некоторые пытаются создать в ваших головах. И да эта проблема имеет место только в плохих ядрах OS и плохих компилятора, линковщиках.

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

108. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от анонимуслинус (?), 15-Окт-20, 14:14 
ну я как раз и понимаю, что проблема не самого языка. скорее тех кто пишет на нем. если уж говорить про с/с++, то он и правда требует более высокой квалификации, но взамен дает боле мощный и управляемый инструмент. просто этот инструмент требует хорошего понимания и знания, а народ малость обленел. им здесь и сейчас и попроще. естественно мало кто хочет тратить столько времени на познание языка. это как авто с механикой и автоматом. механика дает управление точнее, но автомат проще.
Ответить | Правка | Наверх | Cообщить модератору

109. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (109), 15-Окт-20, 16:30 
За 100500 лет может и смогут поцтеринги что-то переписать на раст.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

90. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +3 +/
Сообщение от Аноним (89), 15-Окт-20, 08:34 
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке

Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.

Данной уязвимости НЕСУЩЕСТВУЕТ!

Возможен максимум DoS или падение ядра NetBSD, в зависимости от политики реализации защиты от переполнения буфера при отсутствии проверки границ буфера в ядре NetBSD.

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

101. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 15-Окт-20, 10:19 
Очень интересно. В каких ОС ещё есть подобная защита, в каких нет? Особенно интересно про остальное семейство BSD и Linux.
Ответить | Правка | Наверх | Cообщить модератору

112. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (113), 16-Окт-20, 09:07 
Посмотри информацию на официальных сайтах интересующих OS.

Надо учитывать что вариантов W^X есть 3:

1. Защита строгая и бескомпромиссная.
2. Защита декларативная и дырявая.
3. Защиты нет.

В тех OS и сообществах где есть пропаганда и насаждение технологий JIT - никакой защиты W^X быть не может в принципе, по определению.

Дискретный контроль доступа (DAC) - фундамент безопасности с 1960-тых. И главное правило DAC: "все что исполняется не должно изменятся, а что изменяется не должно исполнятся" (W^X) сегодня реализован с той или иной степенью строгости и корректности во всех коммерческих OS: Unix, Microsoft, Apple.

Примеры GNU/Linux и *BSD:
NetBSD - строгая
OpenBSD - дырявая
GNU/Linux DYSTRYK - строгая https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
GNU/Linux Ubuntu - отсутствует.

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

114. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 16-Окт-20, 09:29 
Спасибо за ответ. А в чём отличие дырявой от строгой?
Ответить | Правка | Наверх | Cообщить модератору

115. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (113), 16-Окт-20, 09:54 
Строгая это строгая без копромисов. Когда разработчики ядра строго и без копромисов отказывают всем в поддержке JIT-подобным технологиям.

Дырявая это когда разрабы ядра прогнулись, пошли на компромисс и оставили возможности запуска JIT-приложений и работы JIT-компиляторов.

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

116. "OpenBSD с JIT и дырой в W^X."  –1 +/
Сообщение от Аноним (113), 16-Окт-20, 10:00 
Тео Де Раадт прогнулся, стал раком перед JIT и отказался от строгой защиты памяти в OpenBSD: https://www.opennet.ru/opennews/art.shtml?num=50763

Теперь в OpenBSD есть возможность запуска ненужных JIT-приложений и большая дырень в W^X для реализации эксплоитов на базе переполнения буфера.

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

119. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 14:42 
Ты путаешь юзерспейсный и ядерный W^X. Ыксперд млин.

Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X. И очевидно, что юзерспейсный влияет только лишь на прикладные приложения с jit, типа браузеров.

И там да, в openbsd не стали делать самый дубовый из возможных вариантов противодействия, а именно - ломать возможность делать mprotect'ом +x для участка памяти принудительно. Если автор приложения уверен, что подобное его приложению и не нужно - он может отозвать prot_exec через pledge. Причём, в любом нужном участке кода программы, а не только сразу после старта. А не учить своё приложение гадать в рантайме, умеет mprotect в prot_exec или нет (или прибивать, в зависимости от настроек).

Но фанатикам, не умеющим думать, умеющим только повторять за другими, понять этого сложно.

PS: мне тут один "неумный" рассказывал, что умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.

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

121. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 16-Окт-20, 15:05 
>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.

А если в Linux, то возможен?

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

122. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 15:15 
>>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.
> А если в Linux, то возможен?

Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю.
Но, судя, например, по https://www.opennet.ru/opennews/art.shtml?num=53892 - remote root там таки возможен.

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

129. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (125), 16-Окт-20, 18:03 
> linux ... remote root там таки возможен

Только в дистрибутивах для быдла.

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

158. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 18-Окт-20, 22:29 
А какие не для быдла?
Ответить | Правка | Наверх | Cообщить модератору

161. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (161), 19-Окт-20, 08:54 
Ссылку на пример дал: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112

Проверить любой *NIX, для быдла он или для людей можно двумя командами:

1. paxtest blackhat

2. checksec --file=/bin/ls

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

138. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним (138), 16-Окт-20, 22:52 
То есть, NetBSD - мощь, а Linux маломощный, так сказать.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

160. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (160), 19-Окт-20, 08:19 
Все зависит от дистрибутива Linux.
Ответить | Правка | Наверх | Cообщить модератору

162. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (161), 19-Окт-20, 09:12 
> Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю.

А давай посмотрим на корень проблемы?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Executable code and read-only data must not be writable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any areas of the kernel with executable memory must not be writable.
While this obviously includes the kernel text itself, we must consider
all additional places too: kernel modules, JIT memory, etc. (There are
temporary exceptions to this rule to support things like instruction
alternatives, breakpoints, kprobes, etc. If these must exist in a
kernel, they are implemented in a way where the memory is temporarily
made writable during the update, and then returned to the original
permissions.)

In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not
writable, data is not executable, and read-only data is neither writable
nor executable.

Most architectures have these options on by default and not user selectable.
For some architectures like arm that wish to have these be selectable...

Корнем проблемы и раздора есть фраза: "There are
temporary exceptions to this rule to support things like ..." вот из-за этих временных исключений в некоторых дистрибутивах GNU/Linux есть дыры. В строгих дистрах GNU/Linux исключений не делают, в них уязвимостей нет, нет и дерьма типа: firefox, JIT, orc, java, ...

> remote root там таки возможен.

Не во всех дистрибутивах GNU/Linux. Есть дистрибутивы GNU/Linux в ко орых эксплуатация любых уязвимостей переполнения буфера (bufferoverwrite) невозможна.

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

128. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (125), 16-Окт-20, 18:01 
> в openbsd не стали делать самый дубовый из возможных вариантов противодействия, а именно - ломать возможность делать mprotect'ом +x для участка памяти принудительно. Если автор приложения уверен, что подобное его приложению и не нужно - он может отозвать prot_exec через pledge. Причём, в любом нужном участке кода программы, а не только сразу после старта. А не учить своё приложение гадать в рантайме, умеет mprotect в prot_exec или нет (или прибивать, в зависимости от настроек).

В OpenBSD Тео отдал программисту право изменят исполняемый код программы. И это очень плохо. Я на стороне строгой реализации W^X не допускающий JIT в принципе.

Тео поступил плохо, мотивируя что chrome & firefox требуют JIT. Google таки прогнулся под Apple в которых тоже строгая реализация W^X и нетерпимость к JIT - сегодня хромого можно собрать без поддержки JIT!

И какому такому "умному" пользователю OpenBSD нужны проги с JIT?

> умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.

PAX - правильная реализация строгой защиты памяти которая таки дает гарантии!

Только если при сборке ядра разрешить отключать защиту для некоторых бинарей:
CONFIG_PAX_XATTR_PAX_FLAGS=y
https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
то откроется дыра и с помощью paxctl-ng можно отключать, дискретно, некоторую защиту по файлам, храня информацию в xattr файловой системы (может и в заглавиях бинарей) это значит что админ может отключить какую-то защиту:
* постраничный защиту памяти
* посегментную защиту памяти
* защиту памяти mprotect
* мелкие области памяти emutramp
* рандомизацию адресного пространства
Защиту pax атрибутов можно организовать простым патчем к IMA/EVM. И при этом есть гарантии неизменности PAX атрибутов. Если вы отключили защиту для некого бинаря то защиты естественно у вас нет, но это ваш выбор, как и выбор CONFIG_PAX_XATTR_PAX_FLAGS=y

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

130. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 18:25 
> Тео отдал программисту право изменят исполняемый код программы.

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

> Я на стороне строгой реализации W^X не допускающий JIT в принципе.

Как только объективной потребности в этом не будет - её все отключат. Пока это может сломать приложения, так делать нельзя.
(речь в большей степени про запрет на переключения RW -> RX, сам по себе W^X уже ломает не так много)

> Тео поступил плохо, мотивируя что chrome & firefox требуют JIT. Google таки прогнулся под Apple в которых тоже строгая реализация W^X и нетерпимость к JIT - сегодня хромого можно собрать без поддержки JIT!

Судя по https://developer.apple.com/documentation/apple_silicon/port... переключения между RW / WX возможны, т.е. всё аналогично openbsd.

> И какому такому "умному" пользователю OpenBSD нужны проги с JIT?

Мне например - firefox без prot_exec не работает. Firefox не нужен?

>> умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.
> PAX - правильная реализация строгой защиты памяти которая таки дает гарантии!

Мне тут рассказывали (проверять поленился, ибо неинтересно), что подгрузить so'шку (со всеми вытекающими) можно даже при включённом pax mprotect. Т.е. строгость, видимо, таки мнимая.

>[оверквотинг удален]
> заглавиях бинарей) это значит что админ может отключить какую-то защиту:
> * постраничный защиту памяти
> * посегментную защиту памяти
> * защиту памяти mprotect
> * мелкие области памяти emutramp
> * рандомизацию адресного пространства
> Защиту pax атрибутов можно организовать простым патчем к IMA/EVM. И при этом
> есть гарантии неизменности PAX атрибутов. Если вы отключили защиту для некого
> бинаря то защиты естественно у вас нет, но это ваш выбор,
> как и выбор CONFIG_PAX_XATTR_PAX_FLAGS=y

Всё вышенаписанное можно свести к более простому, если без фанатичного переливания из пустого в порожнее:

1) Гарантий нет, защиты можно отключить на лету
2) А если собрать ядро так, что их отключить будет нельзя, работать будет не только лишь всё, что для ОС общего назначения неприемлемо.
3) per doll it sya ради "неизменных PAX атрибутов" никто не будет. Единственная ОС общего назначения, где есть pax mprotect из коробки - netbsd, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.

Короче, блажен кто верует.

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

133. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (125), 16-Окт-20, 19:01 
> стандарты POSIX. Которые предполагают, что память может быть доступна и на запись и на чтение

На исполнение и на запись одновременно нельзя! Это вопрос безопасности.

> Как только объективной потребности в этом не будет - её все отключат

А объективной потребности и нет. Ее пытаются создать навязывая никому ненужный JIT, чтобы иметь дыру для реализации эксплоитов с переполнение буфера.

> https://developer.apple.com/documentation/apple_silicon/port...

А Google говорит что Apple их с JIT в chrome послали очень грубо и сказали принести такой же но уже без JIT и Google принес: https://v8.dev/blog/jitless

В Appleb iOS реализация W^X таки строгая?

> firefox без prot_exec не работает. Firefox не нужен?

Мне сегодня уже не нужен. Но когда был нужен запускал без JS и с собранными дополнениями в файловом менеджере. JIT firefox нужен для загрузки дополнений пользователем, а это тоже зло. Попробуй может взлетит и сегодня.

> Мне тут рассказывали (проверять поленился, ибо неинтересно), что подгрузить so'шку (со всеми вытекающими) можно даже при включённом pax mprotect. Т.е. строгость, видимо, таки мнимая.

Там много чего надо включать для полной защиты от "всех сишных дыр". И защита таки есть! Вот пример хорошего дистра GNU/Linux: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

> 1) Гарантий нет, защиты можно отключить на лету

Ложь. В нормально настроений системе не отключить.

> 2) А если собрать ядро так, что их отключить будет нельзя, работать будет не только лишь всё, что для ОС общего назначения неприемлемо.

Все теперь собирается без JIT и работает, даже шпионский хром.

> Единственная ОС общего назначения, где есть pax mprotect из коробки - netbsd, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.

Это у теба единственная которую ты знаешь.

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

137. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Дон Ягон (ok), 16-Окт-20, 19:53 
>> стандарты POSIX. Которые предполагают, что память может быть доступна и на запись и на чтение
> На исполнение и на запись одновременно нельзя! Это вопрос безопасности.

На колу мочала, начинаем всё сначала. Оставь, пожалуйста, свои "наивные" эмоции и восклицательные знаки. А также очевидные, но бессмысленные утверждения.

>> Как только объективной потребности в этом не будет - её все отключат
> А объективной потребности и нет. Ее пытаются создать навязывая никому ненужный JIT, чтобы иметь дыру для реализации эксплоитов с переполнение буфера.

Ты так считаешь? Ну вот, пока я не закрыл man security нетбсдшный:

"     PaX MPROTECT affects the following three uses:

           ·   Processes that utilize code generation (such as the JVM) might
               need to have MPROTECT disabled.

           ·   Miscompiled programs that have text relocations, will now core
               dump instead of having their relocations corrected.  You will
               need to fix those programs (recompile them properly).

           ·   Debugger breakpoints: gdb(1) needs to be able to write to the
               text segment in order to insert and delete breakpoints.  This
               will not work unless MPROTECT is disabled on the executable.
"

Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям.

>> https://developer.apple.com/documentation/apple_silicon/port...
> А Google говорит что Apple их с JIT в chrome послали очень грубо и сказали принести такой же но уже без JIT и
> Google принес: https://v8.dev/blog/jitless

Ни слова про грубый посыл от apple. Хром у меня в mac os работал в те времена, когда W^X в ней уже был (10.4+), а jitless в хромом ещё не было. Ты гони, как говорится, но не загоняйся.

> В Appleb iOS реализация W^X таки строгая?

Возможно, в мобильной версии. В десктопной - нет.

>> firefox без prot_exec не работает. Firefox не нужен?
> Мне сегодня уже не нужен. Но когда был нужен запускал без JS и с собранными дополнениями в файловом менеджере. JIT firefox нужен для загрузки дополнений пользователем, а это тоже зло. Попробуй может взлетит и сегодня.

W|X емнип лисе уже не нужен довольно давно. А вот возможность делать переключения RW -> RX (в предыдущем сообщении я ошибочно написал "-> WX", лол) - нужна. А pax mprotect, он же (в терминологии чуваков из hardenedbsd) W^X pt2 ломает как раз именно эту возможность.

> Это у теба единственная которую ты знаешь.

Да, васин самосборный дистрибутив мне правда неинтересен. А netbsd таки хоть кем-то но используется.

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

155. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +1 +/
Сообщение от Аноним (155), 18-Окт-20, 14:43 
> Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям.

Да, java в W^X работать не будет. Собираю все без java, jit, orc, ...

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

Gdb в рабочей системе никто не держит - уязвимость.

>Возможно, в мобильной версии. В десктопной - нет.

В новых версиях Mac OSX могли W^X добавить программный для Ынтель процов.

> вот возможность делать переключения RW -> RX

Это неприемлемо в плане безопасности. PaX вполне корректно убивает такой процесс. Исправлять надо именно firefox!

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

140. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Карабьян (?), 17-Окт-20, 01:01 
Дополнения в файловом менеджере - как это?
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

156. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (155), 18-Окт-20, 14:47 
Дополнения к бровзеру должны распространятся стандартным ПАКЕТНЫМ менеджером. У меня emerge их собирает. И пользователь не должен устанавливать левые.
Ответить | Правка | Наверх | Cообщить модератору

117. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (117), 16-Окт-20, 12:24 
> Данной уязвимости НЕСУЩЕСТВУЕТ!

Значит NetBSD обновлять не надо!!! А то и к ней уже добрались и под видом исправления через обновление Троян забросят...

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

118. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 16-Окт-20, 13:08 
Взломать нельзя, но ядро упасть может. Написано же было.
Ответить | Правка | Наверх | Cообщить модератору

126. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  –1 +/
Сообщение от Аноним (125), 16-Окт-20, 17:13 
> ядро упасть может

У меня нормальные сетевухи, а не usb. Мне и думаю остальным обновлялся не надо.

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

150. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 18-Окт-20, 11:54 
Почему тогда есть пакет с jit?
https://pkgsrc.se/lang/LuaJIT2
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

153. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (155), 18-Окт-20, 14:26 
При включенной строгой W^X любые потом с JIT работать не будут.

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

Я считаю что проблема безопасности в толерантности, нада жостко, сразу послать всех с JIT на убунту или винду. А то эти сволочи сначала JIT в *опу засунут, с потом и systemd, dbus, polkitd...

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

154. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (155), 18-Окт-20, 14:27 
s/потом/проги/ - вражеский спелчекер.
Ответить | Правка | Наверх | Cообщить модератору

157. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (100), 18-Окт-20, 16:24 
А эта защита включена по умолчанию в netbsd?
Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

159. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."  +/
Сообщение от Аноним (160), 19-Окт-20, 08:14 
Не смотрел. Но должно быть да. Иначе тогда какой в ней смысл?

Здесь лучше ставить два вопроса:

1. Включена ли защита в OS по умолчанию?
2. Есть ли гарантия невозможности отключения защиты в рабочей системе?

От защиты которую можно отключить одной командой толку мало.

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

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

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




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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