Выявлена критическая уязвимость в PolKit, позволяющая повысить привилегии в большинстве дистрибутивов Linux

Посоны похоже линуксы ушли переустанавливать

И какими же сёвыми средствами его можно было предотвратить?

А какими сёвыми средствами можно предотвратить твой тупняк?

Кравица?

Центральный оффициальный репозиторий программ

В. Янукович, проффесор.

А на ведройде есть polkit?

Уже спрашивали.

Похоже нет, на 8.1GO не нахожу

Все дружненько переводим десктопы на OS Haiku !!!

GTK3 в ней уже из каропки/из репы ставится ровненько - GIMP и Inkscape …..

Qt5 и Qt6 давно завезли. OpenJDK есть.

WINE 6 на подходе в продакшен…..

https://t.me/haiku_ru

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

Я имел в виду этот камент. У меня вообще ощущение, что тупорылая виндошколота, добравшись до юникса, напихала туда всякого нахрен ненужного корявого говна чисто по NIH-принципу.

Довольно верно подмечено, в принципе согласен.
Держи ящик пива.

Добавлю ещё подробнее про протоносекту и игрорадости. Идиоты.

причём тут systemd ещё раз?

Какой самый удобный формат для написания и просмотра правил контроля доступа?

Обновление Fedora в KDE Plasma 5 (комментарий)

systemd, dbus, polkitd+JS не нужны совсем:

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

десктопы на OS Haiku !!!

Какой у нее уровень безопасности? Никакой!

Когда DAC завезут? Никогда!

Извиняюсь, ядро гибридное у нее и DAC с MAC планируют прикрутить:

http://www.haiku-os.org/community/forum/what_security_framework_is_planned_dac_mac_grsec_pax_selinux_porting_to_haiku

Нет, в головах разрабов Haiku таки до сих пор отсутствует понимание самой необходимости DAC в OS: https://discuss.haiku-os.org/t/multi-user-support/11099/7

Не важно, что только один пользователь работает за компом. Все равно OS должна обеспечивать разделение прав с дискретностью хотя бы по пользователям (DAC):

1. Проведении ядра

2. Привилегии администратора

3. Привилегии пользователя

4. Привилегии сервисов

Еще желательно иметь возможность выделять частично привилегии некоторым программа, с дискретностью программа, процес (CAP).

1. ping

2. Запись CD/DVD

Чтобы не давать всего рута с помощью SUID.

Уровень безопасности в OS Haiku - никакой.

Отважный анонимус!

Хвала твоей гордыне не иссякнет в рядах юзверей.

Зайди в чат/на форум и вправь мозги разрабам OS Haiku - укажи верный путь товарисчам!!!

doas — это, конечно, лучше чем sudo, а sudo лучше чем polkit. Но можно ещё проще, и без игр с потенциально небезопасным повышением привилегий. Вот так сделано в OpenBSD:

$ ls -l /sbin/shutdown
-r-sr-x---  1 root  operator  276024 Jan 15 20:56 /sbin/shutdown

Достаточно просто добавить юзера, которому позволено делать shutdown, в группу operator:

# usermod -G operator user

Почему-то никто не подчеркнул, что уязвимостей подобного типа в вашей системе прямо сейчас десяток-другой, но вы о них не знаете, и вопрос лишь в том. кто быстрее о них узнает — вы или хакер. Это прямое следствие упарывания сишкой. Написанная на Си система не бывает безопасной. Точка. В лине точно так же по 12 лет лежат уязвимости повышения прав, а потом «ой, у нас с 2.6.27 по 4.20.17 дыра в драйвере IPv6, советуем срочно пропатчиться».

вопрос лишь в том. кто быстрее о них узнает — вы или хакер

Подчёркиваю: злоумышоенник уже́ знает про эти уязвимости.

Сишка ни при чём. На любом языке можно писать глупости. У тебя, вон, даже на русском это неплохо получается xD

doas — это, конечно, лучше чем sudo, а sudo лучше чем polkit

Спорно. Никакого конечно тут быть не может.

Ubuntu 18.04.2 LTS, на одном из серверов, все ок

Сишка ни при чём. На любом языке можно писать глупости. У тебя, вон, даже на русском это неплохо получается xD

Чтобы «на любом языке» написать удаленное выполнение кода, нужно сделать вполне явный eval/exec. Чтобы написать удаленное выполнение кода на сишке, не нужно делать ничего — просто пиши любой сетевой код. Java получила свою популярность не потому, что она такая замечательная, а потому что реальной альтернативой в конце 90-х/начале нулевых был только C/C++, а любой сервис на C/C++ — это одна сплошная дыра в безопасности, в то время, как ошибки логики на жаве в большинстве случаев не представляет угрозы.

Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

Это тот самый случай exec/eval, когда рукожопый разраб написал запуск на выполнение рандомных строк из логов. Но это исключение, а выполнение кода в сишке — это правило.

Интересно, а ФСТЕК вообще

Конечно нет, что ты как маленький. У меня когда-то очень давно (ну да, лет двадцать тому, но что-то я сомневаюсь, что с тех пор что-то изменилось) они не заметили открытый TCP-порт, через который можно было с софтиной сделать что угодно. Ну, типа, одни (вот прямо-таки лично я) этот порт придумали, другие не успели его внести в документацию, а третьи, не спросивши первых двух, отправили софтину сертифицироваться на отсутствие незадекларированных возможностей. Не, ну это была не уязвимость, конечно, и не бекдор, поскольку слушался только localhost, там проверялись всякие пароли и коды и всё такое прочее, но что эта возможность была ‘‘‘незадекларирована’’’ – ну вот просто-таки факт.

Но дело даже не в этом. Тут есть кто-нибудь, кто реально верит в саму физическую возможность «проверить» софтину?

Тут есть кто-нибудь, кто реально верит в саму физическую возможность «проверить» софтину?

Теоретически, если очень надо, то можно наверно. Только надо проверять всё с самого начала - с самого ядра, всех библиотек, всё документировать, лишнее выкидывать. Но это долго, дорого и умных спецов наверно нет... :(

Java получила свою популярность не потому, что она такая замечательная, а потому что реальной альтернативой в конце 90-х/начале нулевых был только C/C++, а любой сервис на C/C++ — это одна сплошная дыра в безопасности, в то время, как ошибки логики на жаве в большинстве случаев не представляет угрозы.

Тут есть одна проблемка. Знаешь, на чём JVM написана?

умных спецов наверно нет… :(

Самые умные спецы из известных мне, причём реально оказывавшие услуги security audit, всегда утверждали, что отрицательный результат аудита означает лишь то, что лично они уязвимостей не обнаружили, но вовсе не то, что их нет. И это, пардон, логично. Доказательное программирование как «перспективное направление блаблабла» благополучно увяло, не выдержав прущей из всех щелей алгоритмической неразрешимости, а предполагать, что человек почему-то может то, чего принципиально не может и никогда не сможет компьютер, ну, как-то странно, что ли.

Тут есть одна проблемка. Знаешь, на чём JVM написана?

Знаю, только риски на порядки ниже, по соотношению объема сишного кода. По этой же причине среднее приложение на C# менее безопасно — шарп сильно полагается на нативные либы, как тот же питон. И по этой же причине питон еще менее безопасен, чем шарп — потому что питон вообще весь слеплен из сишки, и даже то, что могло бы быть написано на питоне, все равно написано на сишке.

Самые умные спецы из известных мне, причём реально оказывавшие услуги security audit, всегда утверждали, что отрицательный результат аудита означает лишь то, что лично они уязвимостей не обнаружили, но вовсе не то, что их нет

Есть разная степень такой уверенности. Когда у тебя система начинается с неотключаемого аппаратного бэкдора в каждом компьютере, то о каких гарантиях безопасности может идти речь? Слишком много неизвестных, но отсюда не следует вывод, что с этим ничего нельзя сделать, мол «все равно все умрём будем взломаны».

Java

Ясно, сектант в треде. Притом ещё толком и не разобравшийся. «Уязвимость» в polkit — это всего лишь симптом. Настоящая уязвимость — в glibc, которая толком не подчищая переменные окружения вызывает из экзешников с suid что попало.

А жабка популярна лишь потому, что её насильно везде пиарят и пихают с самого рождения. Да и не популярнее уж сишечки-то будет. Чем ты этот факт объяснишь? А он объясняется очень просто: на жабе криворукние макаки пишут софт, который никому не упёрся, кроме заказчика, а на Си — нормальные пацаны пишут реальные программы, которые реально используются. Джова с её багами — она как неуловимый Джо из анекдота.

Но ты продолжай слепо веровать в чистоту и непорочность этого проприетарного поделия. Небось и в исходники-то даже ни разу не заглядывал? Да и где бы была твоя жаба, если бы не Си? А её не было бы! До сих пор, вон, в исходниках полно «позорного сишного» кода, ай-ай. Оригинальный Си, к твоему сведению, был написан на асме. Не на жабе. Ахах

Сколько экзешников в твоей системе, написанных на жабе, имеют установленный suid-бит? А сколько в мире существует операционных систем, написанных на жабке? Где же вся эта её немыслимая популярность? Как только консервативный банковский сектор забросит писать на жабе, так в тот же день про неё все и забудут. Но ты не переживай, те динозавры слишком инертны, чтобы сделать это в ближайшем будущем, и на твой век задач по патчингу легаси ещё хватит.

Ну, и хватит, пожалуй :)

на жаве под андроид пишут щас еще.

Да гугл явно уже сам сто раз пожалел, что связался с этими проприетастами. То-то они свой дротик сейчас везде суют.

Настоящая уязвимость — в glibc, которая толком не подчищая переменные окружения вызывает из экзешников с suid что попало

То есть, два раунда удаления переменных окружения (ld.so и самим pkexec) — это по-твоему «толком не подчищая», а вот тройные слои никсового наследия вплоть до 70-х годов, в которых чёрт ногу сломит — это норм? И доступ за пределами буфера — тем более норм, всегда так делаю, я же сишник.

А жабка популярна лишь потому, что её насильно везде пиарят и пихают с самого рождения

Это было актуально по состоянию на конец 90-х/начало нулевых. И вообще-то этот занимательный факт на лор я притащил, с конкретными цифрами маркетинговых бюджетов Sun Microsystems.

Да и не популярнее уж сишечки-то будет

По состоянию на 2022? Да. Потому что есть Node.js и Go на серверах.

А он объясняется очень просто: на жабе криворукние макаки пишут софт, который никому не упёрся, кроме заказчика, а на Си — нормальные пацаны пишут реальные программы, которые реально используются

А на Си тоже пишут криворукие макаки софт, который никому не уперся, кроме заказчика. Прикинь.

А сколько в мире существует операционных систем, написанных на жабке? Где же вся эта её немыслимая популярность?

Пхах, 80% мировых смартфонов крутят одну сплошную JVM систему на лине.

это по-твоему «толком не подчищая»

Вот, полюбуйтесь, граждане, на логику смузихлёба. Конкретно этот CVE нам и говорит о том, что glibc не стоит доверять любому экзешнику, из которого её вызывают, а следует перепроверять все переменные перед каждым вызовом функции, дёргающей сторонние либы. Очевидно, тех двух раундов недостаточно.

И доступ за пределами буфера

Ой, а расскажи-ка нам как ты получаешь аргументы и переменные окружения со стека, не вылезая за пределы жабского «буфера». Что за интересная там у тебя магия? А что жаба скажет на execv("/usr/bin/java", NULL)? Сегфолтом пукнет поди только?

вообще-то этот занимательный факт на лор я притащил

Да этот факт настолько всем очевиден, что его даже не надо выискивать и притаскивать. Не корпорации бы — и эта жаба ни кому бы не упала.

80% мировых смартфонов крутят одну сплошную JVM систему на лине.

А чего не на JavaOS-то? И что полезного вы там понаписали на эти свои смартфоны? Чатики и прочая мишура, куда не ткни, — на электронах, игры — на юнити. А на жабе что? Прослойка одна только, убери её — и ничего не изменится. Если бы гугл развязал руки разработчикам и не насаждал свои анальные SDK и фреймворки, то никто бы в жизнь с этой прослойкой связываться не стал. Но это же гугл, они любят доминировать. А ты, видимо, любишь когда сзади щекочет.

Я даже поставил себе, чтобы проверить:

$ /usr/bin/java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12)
OpenJDK 64-Bit Server VM (build 17.0.1+12, mixed mode)

$ cat test.c
#include <unistd.h>
int main() {
   execv("/usr/bin/java", NULL);
}

$ gcc test.c && ./a.out 
71704 segmentation fault (core dumped)  ./a.out

$ sed -i 's/java/python/' test.c

$ gcc test.c && ./a.out
Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Пхаха. Эпичненько.

вправь мозги разрабам OS ****** - укажи верный путь товарисчам

Пусть сами ищут, документация, стандарты, разъяснения все давно есть написано.

А если не хотят? Зачем мне со своим уставом в их монастырь лазить?

ЗЫ: А кто знает название организации в США которая занимается вправлением мозгов разрабам ОС? Требуется обращение разабов ОС в эту организацию и за деньги налогоплательщиков США разрабам профессионально вправят мозги на счет необходимости DAC в ОС.

Вот верно все! Не хотят разрабы OS Haiku твои хотелки выполнять.

И нифига с этим делом не поделать. Не заставить. Увы…

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

Конкретно этот и десятки других CVE говорят нам, что нужно запрещать setuid на тех системах, где важна безопасность. Другое дело, что если делать повышение прав доступа правильно, то есть, через отправку сообщения системной службе, то поотваливаются горы никсовых костылей, которые городились с 70-х годов и которые опираются на тот факт, что рутовый процесс является дочерним по отношению к запросившему повышение прав процессу, то есть, унаследует дескрипторы пайпов, файлов, сокетов, переменных окружения, и прочей рандомной херни, угрожающей безопасности работы рутового процесса. Это дыра в безопасности by-design, и тот факт, что большинство разрабов научились подставлять достаточное число костылей до исключения векторов атаки, катит лишь как утешение и оправдание.

А что жаба скажет на execv(«/usr/bin/java», NULL)? Сегфолтом пукнет поди только?

Это defined behaviour в жабе, если чо, там разыменование нулевого указателя. Конечно, не считая того, что жаба с setuid вообще не запускается, по крайней мере на дебиане. Если попытаться поставить в argv ненулевой указатель на любую другую недоступную в исходном процессе область памяти, то дочерний процесс вообще не запустится.

потому что полкит - это как раз в стиле ленни

предотвращается как обычно и везде - хорошими практиками

человек почему-то может то, чего принципиально не может

и никогда не сможет компьютер

ну как бы это так и есть. по определению.

или ты из секты швабов-трансгурманистов?

same shit:

C:>which java

/usr/bin/java C:>which java

/usr/bin/java

C:>java -version

openjdk version «11.0.14» 2022-01-18 OpenJDK Runtime Environment (build 11.0.14+9-post-Debian-1deb10u1) OpenJDK 64-Bit Server VM (build 11.0.14+9-post-Debian-1deb10u1, mixed mode, sharing)

C:>cat >java-test.c <<EOF

#include <unistd.h>

int main() {

execv(«/usr/bin/java», NULL);

}

…

C:>gcc java-test.c && ./a.out

Segmentation fault

C:>sed -i ‘s/java/python/’ java-test.c

C:>gcc java-test.c && ./a.out

Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] on linux2

Type «help», «copyright», «credits» or «license» for more information.

Python 2.7.16

Что это за ОС такая, в которой /usr/bin/python это до сих пор питон 2 в 2022?

если чо, там разыменование нулевого указателя

Нет. Агрументы же не по указателю передаются, а складываются на стек и указатель твой не нулевой, а очень даже валидный, указывающий на область стека. Попробуй объявить char* argv[] = {NULL}; и передать её вместо NULL: execv("/usr/bin/java", argv) — будет то же самое.

Но это мы всё о чём с тобой говорили? А о том, что глупости легко пишутся хоть на чём и язык в этом играет не самую главную роль.

Написанная на Си система не бывает безопасной. Точка.

Да, не бывает, но точно так же, как и на любом другом языке.

ошибки логики на жаве в большинстве случаев не представляет угрозы

Ошибки логики всегда были и будут самой главной угрозой безопасности. Безотносительно языка.

И последний факт, который стоит признать: для Си не существует замены, он с нами навсегда, любим мы его или нет.

иии? это что-то поменяло бы в случае данной тестовой программы>

гонишься за Bleeding Edge?

а как насчёт «out of concern that a large body of existing code could not easily be forward-ported to Python 3»?

Просто интересуюсь.

cat /etc/debian_version 10.11

или ты из секты швабов-трансгурманистов?

Нет, я просто материалист. Ну и реалист. Алгоритмическая неразрешимость – штука довольно упрямая, а вот в экстрасенсов, ясновидящих и прочих кикимор с домовыми я не верю, это да.

а, хорошо!

пусть машин родит нам ребёнка! в прямом смысле слова.