The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Rust включён в число основных языков для разработки платформы Android, opennews (??), 07-Апр-21, (0) [смотреть все]

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


36. "Rust включён в число основных языков для разработки платформ..."  –4 +/–
Сообщение от Аноним (36), 07-Апр-21, 15:50 
Не слушает.
Контроль за корректностью работы с памятью процессов необходимо организовывать с помощью ядра OS и процессора.
Компилятор важен но гарантии безопасности от компилятора ты не получишь, а от ядра OS и процессора получишь гарантии безопасности.
Ответить | Правка | Наверх | Cообщить модератору

41. "Rust включён в число основных языков для разработки платформ..."  –6 +/–
Сообщение от Аноним (41), 07-Апр-21, 16:12 
> необходимо организовывать с помощью ядра OS и процессора

Вот только не существует таких ОС, которые брали бы менеджмент памяти полностью на себя, а если вдруг и есть, то на ОС общего назначения они скорее всего не потянут. Никто не запрещает сейчас взять условный Си, вызвать *alloc на рандомный размер памяти, и разместить там то, что хочется, а если *alloc каким-то образом запретить, то поднимется вой, даже тут, в стиле "олололо опять смузихлебы лезут память не умеют рулить вон из профессии"

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

72. "Rust включён в число основных языков для разработки платформ..."  +1 +/–
Сообщение от Аноним (36), 07-Апр-21, 17:24 
ОС общего назначения корректно работающая с памятью: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

Linux + PAX = https://grsecurity.net/featureset/memory_corruption

BSD + PAX = NetBSD

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

- changing the executable status of memory pages that were not originally created as executable,
- making read-only executable pages writable again,
- creating executable pages from anonymous memory,
- making read-only-after-relocations (RELRO) data pages writable again.

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

101. "Rust включён в число основных языков для разработки платформ..."  –1 +/–
Сообщение от Аноним (101), 07-Апр-21, 20:22 
> ОС общего назначения корректно работающая с памятью: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

На оригинальном сервере папку Linux удалили - http://ftp.linux.kiev.ua/

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

245. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 08-Апр-21, 14:45 
Нет, она не работает с памятью корректно. Всё что она делает -- предотвращает дыры вида "исполнение произвольного кода". Она не предотвращает дыры вида "исполнение не-произвольного кода", она не предотвращает дыры вида "выйдем за границы буфера и перезапишем пару указателей на стеке, чтобы заставить программу поверить, что мы доверенный клиент, которому полагаются повышенные привилегии".
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

266. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (266), 08-Апр-21, 17:12 
Там есть патчи реализующие pax_mprotect (выход за границы буфера, если есть попытка записи в RO область памяти должен детектится) и проги собраны с опциями ssp (защита стека канарейками, переполнение на стеке должно детектится). Патчи безопасности от grsecurity+PAX + UA попытка реализации POSIX тех годов + патчи gcc, glibc и binutils.

При загрузке есть выбор уровня безопасности:
Софтмоде - только логируем
Стандарт - логируем и блокируем
Усиленный - логируем, блокируем + мандатный контроль доступа.

Крайняя версия за август 2008 (на сайт не залили)

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

271. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 08-Апр-21, 17:52 
> Там есть патчи реализующие pax_mprotect (выход за границы буфера, если есть попытка
> записи в RO область памяти должен детектится)

С точностью до размера страницы. Какой у тебя там размер страницы памяти? 4Kb?

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

349. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 18:27 
Если переполнение на стеке, то отловит по любому, канарейку переполнение буфера задавит и ядро убьет процесс.


Давайте не только критику, а и предложения по усилению защиты. ;)

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

353. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 10-Апр-21, 18:50 
> Если переполнение на стеке, то отловит по любому, канарейку переполнение буфера задавит и ядро убьет процесс.

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

> Давайте не только критику, а и предложения по усилению защиты. ;)

Заставить программу следить за размером кусков памяти. До тех пор, пока программа нескомпрометирована, у неё есть теоретическая возможность отслеживать все выходы за границы буферов с точностью до каждого байта. Практически с этим могут быть проблемы, поскольку программа может содержать баги. Вот надо нацеливаться именно на эти баги, и снижать их число, которое вполне возможно снизить на порядок, как минимум.

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

354. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 19:33 
А если рандомизация кучи включена:
CONFIG_COMPAT_BRK is not set

echo 2 > /proc/sys/kernel/randomize_va_space

> Заставить программу следить за размером кусков памяти

Это очень дорого!!! Оно реализуется только в критических приложениях для защиты секретных ключей: openssh, gnupg, ...

Как вы относитесь к общему контролю со стороны ядра ОС о недопустимости вмешательства одних процессов в память других процессов, например YAMA в Linux:

echo 3 > /proc/sys/kernel/yama

Гляньте в Documentation/Security/Yama.txt они утверждают что ptrace закрыт даже для разных процессов одного пользователя это лучше чем:

CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y

Гляньте в https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

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

267. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (266), 08-Апр-21, 17:24 
> она не предотвращает дыры вида "выйдем за границы буфера

PAX_NOEXEC должен блокировать исполнение кода даже при перезаписи если область помечена NX: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

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

273. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 08-Апр-21, 17:57 
>> она не предотвращает дыры вида "выйдем за границы буфера
> PAX_NOEXEC должен блокировать исполнение кода даже при перезаписи если область помечена
> NX: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

PAX_NOEXEC не запрещает выполнять код из страниц, которые помечены как исполняемые. А там знаешь как много всякого интересного? Там, например, нечаянно может оказаться интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые. Правда python'овый код, но какая собственно атакующему разница?

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

348. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 18:24 
> интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые.

Если python запущен другим пользователем, то использовать его исполняемые области памяти не удастся. DAC в DYSTRYK распространяется на странице памяти в оперативе и разделяет пямять одного пользователя от другого.

Сегодня YAMA это запрещает даже если python запущен тем же пользователем.

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

351. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 10-Апр-21, 18:35 
>> интерпретатор python'а, а тот, сволочь такая, будет исполнять код из страниц не помеченных как исполняемые.
> Если python запущен другим пользователем,

python может быть подгружен как библиотека. Если не python, то lua. Если не lua, то eBPF, wasm, guile, js, или что-нибудь ещё с тьюринг-полнотой. А если нет ничего с тьюринг-полнотой, то... не надо недооценивать тьюринг-неполноту, она на самом деле тоже много чего может. Она в некотором смысле даже хуже: от тьюринг-полноты ты хоть знаешь чего ожидать можно, а вот что сможет выжать разум злоумышленника, который полгода размышляет над тем, что можно выжать из данной тьюринг-неполноты, ты никогда не угадаешь.

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

356. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 19:56 
> python, то lua. Если не lua, то eBPF, wasm, guile, js

Меня пару лет назад, наверно через guile, ломанули и подобавляли гадости в исходники моих прог, прям русским языком матюки написали... ;)

Теперь интерпретатор или не ставлю или режу DAC:

groupadd guile
usermod -a -G guile vasya
chown root:guile /usr/bin/guile
chmod o-rx /usr/bin/guile

И не ставлю лишних интерпретатора, компиляторов и прочих сборочных инструментов.

В идеале пользователь запускает только бинари и не имеет доступа даже к /bin/sh

> А если нет ничего с тьюринг-полнотой, то... не надо недооценивать тьюринг-неполноту, она на самом деле тоже много чего может.

Как ее запустить? Допусти защита от ROP в DYSTRYK тоже есть: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

CONFIG_PAX_RAP=y

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

269. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (266), 08-Апр-21, 17:32 
Строгого контроля за границами буфера как в KASAN и KFence https://www.opennet.ru/opennews/art.shtml?num=54671 конечно нет. Дистр собран gcc-3 с патчами pie и ssp это середина нулевых.

По странично или посегментно отлов переполнений буфера есть.

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

270. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (266), 08-Апр-21, 17:42 
> не предотвращает дыры вида "исполнение не-произвольного кода"

Атак ввиде "code reuse attacks" тогда не было, они дорогие. Защиты от ROP в тех версиях нет, защита от ROP относительно недавно появилась.

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

272. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 08-Апр-21, 17:55 
>> не предотвращает дыры вида "исполнение не-произвольного кода"
> Атак ввиде "code reuse attacks" тогда не было, они дорогие. Защиты от
> ROP в тех версиях нет, защита от ROP относительно недавно появилась.

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

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

347. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 18:17 
> Если ты подменишь строку "*" на строку "/*", перед тем как эта строка будет передана в rm, то результатом будет удаление всех файлов.

/ система там защищена от удаления rm -rf /.

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

Защита процессов некая там есть. Можно портить процессы только своего пользователя, процессы в памяти других пользователей защищены от записи и чтения их неиспортишь. Защита процесов не такая сильная как сегодня в YAMA, но она проста и эфективна.

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

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

350. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 10-Апр-21, 18:31 
>> Если ты подменишь строку "*" на строку "/*", перед тем как эта строка будет передана в rm, то результатом будет удаление всех файлов.
> / система там защищена от удаления rm -rf /.

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

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

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

> В дополнение рандомизация адресного пространства ASLR сильно затрудняет поиск в памяти
> нужного места для записи. Необходимо брутыосить и в логах это будет
> видно, можно и пользователя прибить за плохое поведение с памятью.

Да. Продолжай накладывать одну заплатку поверх другой. Я верю, что со временем это приведёт к системе, которую невозможно эксплуатировать. Есть некоторые сомнения -- не упадёт ли система раньше под весом заплаток, но я думаю что нет, она выдержит.

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

357. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (349), 10-Апр-21, 20:23 
> Продолжай накладывать заплатку поверх заплатки

Никто бездумно заплатки на дыры не накладывал. Или поведение ядра приводилось в соответствии стандарту POSIX или уязвимости групировались в классы и разрабатывалась одна техника защиты от целого класа уязвимостей.

> Переменные окружения позволяют прокинуть в них произвольные данные,

Это да. В идеале шелы можно закрыть и исключить возможность изменения переменных окружения.

> а LD_PRELOAD подгрузить произвольный код. В секцию, которая EXEC

1. Как идея со сборкой всех бинарей статически, например как в AlpinaLinux? Есть минус в рандомизация, бинари с разделяемыми библиотеками лучше рандомизируются в памяти.

2. RO / или Integrity не дадут подгрузить лишнего.

> Если же ты полагаешь, что защита процессов проста и эффективна, то зачем ты вообще паришься защитой памяти?

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

> Да. Продолжай накладывать одну заплатку поверх другой.

Бездомных заплаток не накладывал, все усиления безопасности в DYSTRYK хорошо систематизированы и структурированы.

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

373. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 11-Апр-21, 13:14 
>> Продолжай накладывать заплатку поверх заплатки
> Никто бездумно заплатки на дыры не накладывал. Или поведение ядра приводилось в
> соответствии стандарту POSIX или уязвимости групировались в классы и разрабатывалась одна
> техника защиты от целого класа уязвимостей.

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

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

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

Ты не слышал про wuffs[1]? Язык, который видя a[i], пытается доказать, что i не выйдет за границы массива, и если ему это не удаётся, выкидывает ошибку компиляции. Мне очень понравилась идея. То есть ты пишешь a[i], и если компилятор не смог доказать, то надо добавить if(i < 0 || i > a.len()) { return Error } перед индексацией, после этого компилятор сможет доказать. Это, кстати, в некотором смысле подход противоположный rust'у: в расте стандартная библиотека принудительно втыкает проверки, и если компилятор потом может доказать, что они не нужны, он их удаляет. Не может, не удаляет. wuffs даёт больше контроля программисту, при этом заставляя его доказывать, что проверка не нужна, если тот хочет от неё избавиться.

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

[1] https://github.com/google/wuffs

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

404. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (404), 17-Апр-21, 12:37 
1. Вы делаете туже ошибку, что создатели Rust. Гарантии безопасности может дать только ядро OS и процессор. При этом компилятор очень важен для обеспечения безопасности. Но компилятор не есть ключ к гарантиям безопасности.

2. Вы недоконца поняли проактивную защиту, она не только заменяет дыру на DoS. Да прога упадет, но В ЛОГАХ останется подробная запись о причинах и месте падения. Логи с падением шлем разрабам и они фиксят дыру. Баги при внедрении проактивной защиты не остаются, они все быстро находятся и исправляются.

3. GCC очень сложный, он старается защитить компилируемые проги, в некоторых местах, защищает от переполнения буфера: -D_FORTIFY_SOURCE=2. Целесообразно внедрить -D_FORTIFY_SOURCE=3.
-fPIC  преобразовывает код в позиционно независимый, а -fPIE собирает позиционно независимый бинарь, который в ASLR ядре OS, грузится по разным адресам в памяти и значительно усложняет атаки. Делает их обнаруживаемыми, с записями в логах.
Техника SSP вставляет "канарейки" сигнализирует о переполнении стека.

4. Если интересует компилятор проверяющий индексы можно посмотреть Fortran, Pascal. Для С-ишных прог попробуйте собрать GCC с: --param ssp-buffer-size=1 -fstack-protector-all переполнения индексов в масивах должны отлавливатся, проверьте и отпишите.

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

407. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 17-Апр-21, 13:48 
> 1. Вы делаете туже ошибку, что создатели Rust. Гарантии безопасности может дать
> только ядро OS и процессор. При этом компилятор очень важен для
> обеспечения безопасности. Но компилятор не есть ключ к гарантиям безопасности.

Нет, я не делаю ошибок. Это ты мыслишь админскими категориями, а не программерскими.

> 2. Вы недоконца поняли проактивную защиту, она не только заменяет дыру на
> DoS.

Это если эта проактивная защита сработает. Более того, где сработает проактивная защита? Там где ты совершил ошибку в коде? хехе, нет. Она сработает там, где код разадресовывает dangling pointer, а не там, где ты создал этот dangling pointer. У тебя в логах есть бектрейс? Или даже у тебя есть core dump? Успехов теперь угадать, каким образом этот dangling pointer был создан. Тот стековый фрейм, на котором он был создан, был удалён со стека, может быть за трое суток до того, как этот dangling pointer был разадресован. Более того, может быть ещё более мозговыносящая ситуация: dangling pointer был создан, потом двое суток он не использовался, и поэтому не создавал проблем, потом он начал использоваться, но волею случая он указывал в место, где был выделен какой-то другой объект, и таким образом все эти твои проактивные защиты не видели в этих разадресациях ничего плохого, они считали, что всё ок: указатель ведь в выделенную память указывает? Если тебе повезло, то указатель использовался только для чтения из памяти. А потом этот объект был удалён, и следующее использование dangling pointer'а привело к панике и core dump'у. Если тебе не повезло, то ситуация может быть ещё более мозговыносящей: твоя программа делала что-то типа dangling_pointer->id = 234897, это поле id попадало на поле ptr какой-то структуры, и ты по факту создавал _новый_ dangling_pointer, и в core dump твоя программа упала тогда, когда тот ptr разадресовывался.

А вот теперь, попробуй найти ошибку, которая привела ко всему этому. Я где-то как-то читал о замечательном баге, который выскакивал в программе совершенно непредсказуемо _годами_. Были десятки багрепортов о нём, но найти его никто не мог. И все твои проактивные защиты были бесполезны против него. Если тебе приходилось когда-нибудь пару дней отлаживать C'шную программу, выискивая то место, где ты забыл обнулить указатель, или может быть ты забыл не обнулить его, а индекс неверно высчитал? Или может там переполнение целого где-то случилось? Или, блин, ты не к тому типу привёл void*? Или может ты наступил на грабли UB, и поэтому проверка на NULL как бы и есть в сорце, но её как бы и нет в машинном коде? Если тебе приходилось ковыряться пару суток вокруг такой хрени, то как ты вообще можешь верить в проактивные защиты? А если не приходилось, то это говорит лишь о том, что ты никогда не писал на C, и тогда непонятно, что позволяет тебе верить в действенность защит со стороны ядра или, если уж на то пошло, в ненужность rust'а.

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

> 4. Если интересует компилятор проверяющий индексы можно посмотреть Fortran, Pascal.

Да мне похрен на индексы, ты понимаешь это? Проверка индекса на выход за границы -- это лишь малая часть, того что даёт rust, и реализована она в библиотечном коде с опорой на другие возможности языка, которые позволяют реализовать такое в библиотеке, оформив это няшным и удобным для использования API. То есть, ты вот явно непонимаешь о чём речь, я поясню на примере. Допустим мне вдруг стало неинтересно, что массив паникует, когда я выхожу за границы его. Допустим я решил, что я знаю как обрабатывать в рантайме такую ошибку. Ты понимаешь, что я могу взять и изменить slice таким образом, чтобы index возвращал бы Result? Да, потом мне придётся писать
"arr[i]?" вместо "arr[i]", хм... но и чё? Ну-ка расскажи мне, как я могу паскаль научить не падать с рантайм-ошибкой при выходе за границы массива?

Я тебе очень рекомендую не рассуждать о расте на основании маркетинговых материалов, а взять и попробовать. Просто заценить как это круто, когда все сообщения об ошибках, как compile-time, так и runtime указывают тебе в то место, где ты совершил ошибку, а не в рандомное место соседнего процесса^W^W... ок, в соседний процесс оно не указывает никогда, но ты понял суть, да?

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

408. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (408), 21-Апр-21, 17:26 
> Это ты мыслишь админскими категориями, а не программерскими.

Точка зрения зависит от точки сидения.

> Это если эта проактивная защита сработает.

Когда-то тестировал все эксплоиты на все CVE. Проактивная защита срабатывала всегда и во всех случаях где она была. Показатель 100%.

> А если не приходилось, то это говорит лишь о том, что ты никогда не писал на C, и тогда непонятно, что позволяет тебе верить в действенность защит со стороны ядра или, если уж на то пошло, в ненужность rust'а.

Крайнюю прошу на C написал лет 20 назад. С большим удивлением потом узнал что ее использовали более 5 лет. Да, я не сишник и грубо говоря не программист, если не считать 10 строк на баше.

Меня учили использовать для масивов for и проблем с индексами не было. Учили строго, жестко. Программировать не учили грубо говоря, учили матмоделированию и алгоритмам.

Информативность логов зависят от опций сборки!!! Безопасность тоже. ;)

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

У меня, извиняюсь, органическое отвращение к языкам go, rust. Firefox на расте сложно написать так чтобы не выделялась память в режиме WX? А что сказать о сборки проекта на go: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-p2p/go-ip... 1380 пакетов в зависимостях! Без PGP подписей.

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

Мне, админу C-шные проги лучше.

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

409. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 21-Апр-21, 17:38 
> Меня учили использовать для масивов for и проблем с индексами не было.
> Учили строго, жестко. Программировать не учили грубо говоря, учили матмоделированию и
> алгоритмам.

Да. Поэтому в статистику ты не веришь? Она слишком fuzzy на твой вкус, да? Статистика говорит, что проблемы с индексами возникают везде, где они есть. Но личный анекдотичный опыт важнее статистики?

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

Пфеу. С этого надо было начинать. "Органическое отвращение", ха! Ты ключевым образом не специалист в области программирования и никогда им не будешь. Инструмент выбирается исходя из требований задачи, а не исходя из личного эмоционального отношения. Пока ты к рациональным аргументам не начнёшь относиться серьёзнее, чем к эмоциональным, ты никогда не станешь специалистом.

> Они даже не задумываются пока о бутстрапе, чистом компиляторе.

Вот сейчас ты языком мелешь, демонстрируя что ты абсолютно, совершенно не в курсе. Бутстрап возможен, но слишком сложен. Но при этом вовсю идёт развитие gccrs и mrust. И на фоне этого ты говоришь "не задумываются".

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

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

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

411. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (411), 22-Апр-21, 15:30 
> Статистика говорит, что проблемы с индексами возникают везде, где они есть.

Статистика лжет.

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

> Инструмент выбирается исходя из требований задачи, а не исходя из личного эмоционального отношения.

Как админ, сборщик пакетов, пользователь - утверждаю что раст с го это ад и Израиль! В моих системах их нет. Не попадают раст и го в мой шаблон безопасности...

Дам ссылку на одну статейку, сразу скажу что со многими тезисами автора я категорически не согласен и считаю ошибочными, но автор улавливает некие угрозы го и раст програм: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag.../

Стоимость использования инструмента тоже важна. С-шные проги будут раз в 10 дороже чем на python, это если зарплаты одинаковы.

> при этом вовсю идёт развитие gccrs

Столмана вернем и он это безобразие исправит;) Если gccrs будет собираться дырявой сишечькой то вопрос бутстрапа будет решен. Главное чтобы этот gccrs потом смог собрать оригинальный rust.

> mrust

https://docs.rs/mrust/0.0.1/mrust/ это? Консервативен не смотрел.

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

Точка зрения на язык программирования зависит от точки сидения!

Я не программист!!! Смотрю на раст и го как админ, сборщик пакетов и пользователь. Это точка зрения под другим углом не с нутри, а снаружи..

Firefox написанный на rust некорректно работает с памятью. Этот факт и прочие обусловливает мое отношение к "корректно работаещему" с памятью расту.

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

412. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 22-Апр-21, 15:39 
> Статистика лжет.

Ну я о том же.

> Как админ, сборщик пакетов, пользователь - утверждаю что раст с го это ад и Израиль!

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

> Стоимость использования инструмента тоже важна.

Да, это один из критериев, который надо учитываеть при выборе инструмента. Кстати, если использовать экономические инструменты (вполне применимые), то всё сведётся к стоимости.

> https://docs.rs/mrust/0.0.1/mrust/ это? Консервативен не смотрел.

Нет, вот это: https://github.com/thepowersgang/mrustc

> Firefox написанный на rust некорректно работает с памятью.

Где ты нашёл Firefox написанный на раст? Поделись ссылкой, я бы поставил немедленно. Пока мне доступен лишь ff, в котором и 10% раста нет. И про который, скажем, можно почитать такое: https://hacks.mozilla.org/2021/04/eliminating-data-races-in-.../

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

413. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (413), 12-Май-21, 16:42 
> Очень важно мнение ... сборщика пакетов ... Ведь именно эти группы людей выбирают инструмент для разработки.

Нет. Инструмент выбирает программист.

А если инструмент и программа сборщика пакетов не понравятся, то админ и пользователь этой программой пользоваться не будут.

> https://github.com/thepowersgang/mrustc

Очень нужная для раста вещь.

> всё сведётся к стоимости

И как стоимость разработки на раст в сравнении с питоном.

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

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

415. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Ordu (ok), 12-Май-21, 17:05 
>> Очень важно мнение ... сборщика пакетов ... Ведь именно эти группы людей выбирают инструмент для разработки.
> Нет. Инструмент выбирает программист.
> А если инструмент и программа сборщика пакетов не понравятся, то админ и
> пользователь этой программой пользоваться не будут.

Успехов им писать замену. Я только "за": чем больше программистов, тем лучше.

>> https://github.com/thepowersgang/mrustc
> Очень нужная для раста вещь.

Возможно.

>> всё сведётся к стоимости
> И как стоимость разработки на раст в сравнении с питоном.

Дороже, естественно. А почему ты спрашиваешь?

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

Читай глазами, плз, и не выдирай фразы из контекста. Там написано: "если использовать экономические инструменты (вполне применимые), то всё сведётся к стоимости". Это конструкция если-то, A=>B. Отрицая B, и игнорируя при этом A ты выставляешь себя идиотом, кто учебник по матлогике не открывал ни разу в жизни. Там ведь эти вопросы разбираются в первой главе про натуральный вывод, или как там она называется? Хмм... за двадцать лет я забыл уже. Но в англоязычной литературе это называется propositional calculus.

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

405. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (404), 17-Апр-21, 12:47 
> Язык, который видя a[i], пытается доказать, что i не выйдет за границы массива, и если ему это не удаётся, выкидывает ошибку компиляции. Мне очень понравилась идея.

Вы уловили ценную идею. Лет 10 назад в некоторых дистрибутивах GNU/Linux еще поддерживались флаги GCC:
-Wformat -Wformat-security -Werror=format-security
сегодня люди закончились и сборку с этими флагами дистры уже не тянут...

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

406. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (404), 17-Апр-21, 13:03 
> Это про программу на C хрен что докажешь, потому что C не позволяет статически энфорсить свойства программы.

Не знаю какой у вас дистрибутив GNU/*, BSD* в Gentoo есть такая фича как "проверка качества", устанавливается переменными:
QA_STRICT_* = "set"
FEATURES="... stricter ..."
Все доказательства для разработчиков находятся в файлах:
grep -l 'QA' /var/log/portage/elog/*

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

77. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (77), 07-Апр-21, 18:06 
> и разместить там то, что хочется

Департамент обороны США категорически запрещает с 1983 года:

2.1.3.1.1: «The TCB shall maintain a domain for its own execution protects it from external interference or tampering (e.g., by modification of its code or data strucutres).»

По этому делаю:

echo "appraise func=BPRM_CHECK mask=MAY_EXEC
appraise func=MMAP_CHECK mask=MAY_EXEC" > /sys/kernel/security/ima/policy

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

79. "Rust включён в число основных языков для разработки платформ..."  +1 +/–
Сообщение от Denver (??), 07-Апр-21, 18:31 
Security

Is the FreeBSD team interested in using safer languages like Rust to improve security? Baldwin did not see this as the primary route to more memory safety. "One of the things I work on is a project at Cambridge called CHERI (Capability Hardware Enhanced RISC Instructions) that allow us to push special memory safety into the processor itself, so that you're able to have a much safer version of C itself.

"And that will compose well with languages like Rust. It means we can take the safeness of the language and enforce it further down the stack than we currently can. So my personal bias is I think CHERI is going to be a better solution. FreeBSD is largely written in C and we were able to run the whole base system on CHERI. So we have all of that C code running as a safer C. I think that's the more likely future way to get memory-safe systems."

https://www.theregister.com/2021/03/10/the_state_of_freebsd/

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

181. "Rust включён в число основных языков для разработки платформ..."  –2 +/–
Сообщение от Inim (?), 08-Апр-21, 08:48 
Конечно, если Вы застряли в 60-х, то это заявление - истина, потому, что идея из той эпохи, тогда верили, что программы в 90-х будут летать, интерпретируя лисп или бейсик на интеллектуальных процессорах, обеспечивая тотальный контроль за качеством кода, да, из тех фантазий возник intel432 на аде, да и алгольные суперкомпьютеры... но прошло время, идиоты ушли, пришли другие, банкротства заблуждений никого не учит...
А проблема в другом, проблема си - сам си, он родом из конца 60-х, начала 70-х, он не про программирование, он про 16-и битные контролеры, вся "программа" которого не может "не влезть" в ограниченные рамки (большего все равно никто не даст), и поэтому дискет вполне хватало, и выразительности языка, тем более для программ на 1-2 страницы распечатки. Не нужен был для перфолент "надежный" язык программирования, нужен был язык описания автоматов, тем более в эпоху засилья фортран-программистов и паскаль-апологетов...
Войну с ассемблером си выиграл.., за счет некорректных трюков с освобождением памяти, последствия которых и разгребает раст, а суть проблемы не в памяти, а образовании "программеров" и профов, которые генерят си-фантазии с запахом вишни. Дело в том, что (и в 60-х!) могли писать корректные программы, даже на ассемблерах, только... таких людей - единицы, большинство программистов даже не способно освоит программирование... и раст решает проблему отсеивания последних экземпляров, вызывая у них культурный диссонанс и ненависть к языку, а не к своей необразованности.

Человеку с "такими" взглядами на раст (на язык дающий только инструментарий, а не решение), в профессии делать нечего, он не способен сделать процессор, потому, что это единая система: язык и исполнитель.
А си OS - обречены, тем более такие древние, но если он считает, что можно и дальше откапывать труп Multics... пусть экспериментирует, VM - тоже из той эпохи! и... си - "быстрый" язык для создания супер-медленных систем jit- интерпретирующий java и js в изолированных VM... эпоха победившего разума!

Прекратите тянуть труп из 60-х, tcc генерирует отвратительный код - это тот уровень который может дать си( это предел языка ), а gcc - берет код от "си-программера" и делает из него "вменяемый" по быстродействию, да и только если не брать во внимание код freebsd и более древний, он непредсказуемо крешится после применения оптимизаций -о3... и от черихлеба это никак не зависит, трюки были созданы, когда си-компилятор был туп, и все, что от последнего требовалось - не лезть со своими оптимизациями, просто все во фре - прогнило, и код и идеологи.

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

218. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (218), 08-Апр-21, 11:03 
> дальше откапывать труп Multics

Недавно опять смотрел, ту часть Multics которая касается безопасности. Да это 1960-тые годы. Да прошло уже ~60 лет. И она полностью актуально до каждой буквы и запятой сегодня. 2+2=4 так было есть и будет.

> tcc генерирует отвратительный код

Он нужен только как промежуточный компилятор в процессе бутстрапа.

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

Язык должен быть простой, синтаксис удобочитаемый и легко понимаемый. Иначе будут большые сложности аудита и поддержки кода.

А "програмистов" можно отсеивать на тестовой программе уровня олимпиады. Зачем язык портить?

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

219. "Rust включён в число основных языков для разработки платформ..."  –1 +/–
Сообщение от Аноним (218), 08-Апр-21, 11:09 
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag.../

Rust имеет проблемы с дроблением, а вот статистическую сборку бинаря в плане безопасности я одобряю. ;) C проги для безопасности также надо линковать статически.

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

396. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (396), 14-Апр-21, 05:44 
> Rust имеет проблемы с дроблением, а вот статистическую сборку бинаря в плане
> безопасности я одобряю. ;)

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

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

414. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от Аноним (413), 12-Май-21, 16:52 
Нет я вайтхед :)

А ты расист? Черных не любишь?

Гента выловит завасимости и при статической линковке.

equery d имя_пакета

И по /var/db/pkg/*/*/NEEDED* можно грепнуть.

А проблемы недопакетных менеджеров меня не колышут.

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

236. "Rust включён в число основных языков для разработки платформ..."  +/–
Сообщение от xm (ok), 08-Апр-21, 13:55 
> Контроль за корректностью работы с памятью процессов необходимо организовывать с помощью ядра OS и процессора.

Дело уже идёт к выпуску.
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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