Здравствуйте, scf, Вы писали:
scf>Здравствуйте, FDSC, Вы писали:
FDS>>3. Помечать код как неизменяющий состояние программы
scf>3. Я знаю два способа — const в плюсах и вообще (по-возможности) не иметь методов, изменяющих состояние программы. Т.е. все структуры данных иммутабельные, все "неконстантные" методы возвращают копию структуры данных с изменениями. Это надо смотреть в сторону ФП языков с монадами.
const — не годится. Массив в плюсах const не пометишь.
ФП годятся. Но там тоже проблема будет с массивами. Ибо обработка идёт изменяющихся данных.
Здравствуйте, FDSC, Вы писали:
FDS>Ну, вы сами видите, язык нормальный порекомендовать не смогли в другой теме. FDS>Я же не на ассемблере должен писать?
Не ну если очень хочется то например вот https://github.com/swift-embedded/swift-embedded
Здравствуйте, FDSC, Вы писали:
FDS>Ещё пару вопросов насчёт выбора языка программирования. FDS>Есть ли язык программирования, в котором есть следующие фичи: FDS>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>3. Помечать код как неизменяющий состояние программы FDS>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>Причём нужно, чтобы была возможность автоматически построить список всех явный приведений типов между зелёными и красными (а ещё лучше — запретить) FDS>Аналогично, в идеале, метками, которые запрещают вызов у копии объекта каких-либо методов (например, деструктор или методы, изменяющие состояние). FDS>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Здравствуйте, varenikAA, Вы писали:
AA>А вообще, clojure. AA>Почему? Рич Хикки, автор, в прошлой жизни писал на C++. AA>Но почему-то выбрал JVM. Ибо работает быстро. На уровне мат. операций.
Этот минус JVM Рич исправил, математика на кложури на порядки медленнее.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, FDSC, Вы писали:
FDS>>Ну, вы сами видите, язык нормальный порекомендовать не смогли в другой теме. FDS>>Я же не на ассемблере должен писать? _>Не ну если очень хочется то например вот https://github.com/swift-embedded/swift-embedded
Сколько всяких штук Жесть просто
Но там для конкретных микроконтроллеров, я так понял.
Это, по сути, надо флешку перепрограммировать... чего-то совсем страшное
Я даже боюсь начинать смотреть. У меня и аппаратуры такой нет
Здравствуйте, FDSC, Вы писали:
FDS>·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором. FDS>Это уже вопрос рантайма. Причём может решаться частично организационными методами.
Вряд ли... Хотя если проект из одного человека, то может и сработать.
>>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять. FDS>Нет. Так дело не пойдёт. FDS>Как раз в том-то и дело, что не аудитор должен проверять, а компилятор.
На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?
FDS>·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту. FDS>Да. Но здесь всё просто. По умолчанию, никакая функция ничего не может. Программист должен просто сказать, что функция может. FDS>Важно то, чтобы можно было эти все функции отследить.
Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.
FDS>·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП. FDS>Это вопрос именно ЯП, к сожалению. Потому что я должен иметь возможность ограничить доступ к API. FDS>Даже если второй программист, допустим, злонамеренный. Ну или меня, не знаю, загипнотизировали
Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило.
FDS>·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти. FDS>Да. Верно. Либо сборщик мусора, либо счётчик ссылок,
Счётчик ссылок это тривиальный вариант реализации сборщика мусора.
FDS>либо специализированная система выделения памяти.
Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.
FDS>·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь. FDS>В данном случае предполагается гарантия при правильной работе программы, хотя бы. FDS>При неправильной ничто никогда не гарантирует.
Ну тогда просто — при завершении процесса занулить всю память. Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы?
Просмотрит все вызываемые функции. Они не вызывают функции, которые пишут в файл или в поток ввода-вывода, не вызывают прерываний и не пишут в порты ввода-вывода.
>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё.
Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно.
·>Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило.
Может быть вызов через рефлекшн и непосредственно в коде с полной квалификацией (в C#, по крайней мере).
Ну, опять же, в Java может и не получится. В других языках это не так просто.
Ну и потом, там могут быть алиасы какие-нибудь и т.п.
·>Счётчик ссылок это тривиальный вариант реализации сборщика мусора.
Ну это не сборщик мусора, это немного другое. Но да.
FDS>>либо специализированная система выделения памяти. ·>Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять.
Систем освобождения памяти не бывает Только выделения.
·>Ну тогда просто — при завершении процесса занулить всю память.
не, это слишком долго. Вдруг процесс, всё же, упадёт?
> Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится.
О таким API мне неизвестно. И в файл подкачки вполне утекает всё.
Чтобы не утекало, есть функция VirtualLock в WinAPI
Здравствуйте, Слава, Вы писали:
FDS>>Есть ли язык программирования, в котором есть следующие фичи:
С>Ада, Ада/SPARK
Что-то я там такого не помню...
может плохо смотрел. Не подскажете часть операций?
Например FDS>>2. Аналогичный запрет (операции ввода-вывода, иные вызовы определённых функций) для всех функций, которые вызываются из данной функции
FDS>>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
Здравствуйте, D. Mon, Вы писали:
FDS>>Ещё пару вопросов насчёт выбора языка программирования. FDS>>Есть ли язык программирования, в котором есть следующие фичи: FDS>>1. Необходимо задавать невозможность вызова в модулях функций (запрет файлового ввод-вывода, например), исключая разрешённые модули FDS>>2. Аналогичный запрет для всех функций, которые вызываются из данной функции FDS>>3. Помечать код как неизменяющий состояние программы FDS>>4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной. FDS>>5. Контролировать состояние объекта как конечного автомата, в идеале, в статике. Грубо говоря, объект не инициализирован, объект инициализирован, объект в работе, объект завершил работу, объект подвергся деструкции.
DM>Pony уже смотрел? DM>https://www.ponylang.io/discover/#what-is-pony
Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
Здравствуйте, FDSC, Вы писали:
FDS>Сколько всяких штук Жесть просто
Без этого никак.
FDS>Но там для конкретных микроконтроллеров, я так понял. FDS>Это, по сути, надо флешку перепрограммировать... чего-то совсем страшное FDS>Я даже боюсь начинать смотреть. У меня и аппаратуры такой нет
Не тут всё от задачи зависит. Если что бы ехать C/C++ или доступные скриптовые языки
Если хочется странного то поле не паханное:
Swift компилируются при помощи LLVM так что можете при желании куда угодно компилировать
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, FDSC, Вы писали:
DM>>>https://www.ponylang.io/discover/#what-is-pony
FDS>>Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
DM>Не только, там как раз через capabilities можно хорошо управлять тем, чтобы какие-то функции не могли работать с файлами и пр.
Здравствуйте, FDSC, Вы писали:
DM>>>>https://www.ponylang.io/discover/#what-is-pony
FDS>>>Интересно. Но из перечисленного, я так понимаю, только пометка объектов/ссылок как неизменяемых
DM>>Не только, там как раз через capabilities можно хорошо управлять тем, чтобы какие-то функции не могли работать с файлами и пр.
FDS>Не нашёл
Здравствуйте, FDSC, Вы писали:
FDS>·>На каком основании компилятор будет принимать решение, что некая функция с неким именем calculateHash может или не может писать в файлы? FDS>Просмотрит все вызываемые функции. Они не вызывают функции, которые пишут в файл или в поток ввода-вывода, не вызывают прерываний и не пишут в порты ввода-вывода.
Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл?
>>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё. FDS>Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно.
А если не все, а только 95% функций? А если 5%? Где границу-то ставить?
FDS>·>Так практически любой ЯП это уже умеет. Если в файле не написано "import java.io.*" то io никакого в данном файле быть не может. Немного сложнее, но элементарно делается. Динамическую подгрузку кода не считаем, её можно явно оключить, как правило. FDS>Может быть вызов через рефлекшн и непосредственно в коде с полной квалификацией (в C#, по крайней мере). FDS>Ну, опять же, в Java может и не получится. В других языках это не так просто.
В java это контролируется. Чтобы загрузить класс, тебе нужно сделать classLoader.forName("someClass") — а этот сам classLoader контролируется и может выдавать ClassNotFound. Т.е. коду просто не будет доступа к классам которые ему не дают.
FDS>Ну и потом, там могут быть алиасы какие-нибудь и т.п.
Нет никаких альясов. Есть только имена классов.
FDS>>>либо специализированная система выделения памяти. FDS>·>Тут проблема не в выделении, а в освобождении. Т.к. именно при освобождении надо занулять. FDS>Систем освобождения памяти не бывает Только выделения.
Вот и я о том.
FDS>·>Ну тогда просто — при завершении процесса занулить всю память. FDS>не, это слишком долго.
Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе.
FDS>Вдруг процесс, всё же, упадёт?
Ты уж определись...
>> Интуиция подсказывает, что такое API должно предоставляться операционкой. А то утечёт что-нибудь в своп-файл, сработает какая-нибудь дефрагментация и нифига не занулится. FDS>О таким API мне неизвестно. И в файл подкачки вполне утекает всё. FDS>Чтобы не утекало, есть функция VirtualLock в WinAPI
Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать.
И уже не говоря про всякие железные уязвимости типа row hammer.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, FDSC, Вы писали:
FDS>Например FDS>>>2. Аналогичный запрет (операции ввода-вывода, иные вызовы определённых функций) для всех функций, которые вызываются из данной функции
Всё это в общем-то реализуется через модули, и через Subprogram Contracts
Здравствуйте, ·, Вы писали:
·>Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл?
Программист явно укажет функции, которые могут писать в файл.
>>>Так в итоге в сколько-либо сложном проекте у тебя дойдёт до того, что программист будет говорить что все функции могут всё. FDS>>Не дойдёт. А если дойдёт, значит проект должен выбрасываться и переписываться заново. Когда все функции могут всё — это как раз не то, что нужно. ·>А если не все, а только 95% функций? А если 5%? Где границу-то ставить?
Допустим у нас проект на 20 000 строк кода. 1000 тысяча строк кода может делать всё что угодно. Согласись, есть разница, сколько проверять?
·>Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе.
Гарантированно быстрее вообще не делать.
Обнуление памяти при завершении процесса — это слишком рискованная операция. Обнулять всё должно очень и очень быстро.
FDS>>Вдруг процесс, всё же, упадёт? ·>Ты уж определись...
Одно дело при краше не очистится память и мы не могли очистить, а другое дело, когда при краше можно очистить память, а мы всё равно не очистили.
·>Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать.
Что-то такое
pwdAddress = VirtualAlloc(0, len, 0x1000 | 0x2000 | 0x00400000, 0x04);
·>И уже не говоря про всякие железные уязвимости типа row hammer.
Железные уязвимости оставим железу.
Защититься от всего программными способами невозможно
Здравствуйте, Слава, Вы писали:
С>Я не думаю, что вы найдёте более подходящий язык за исключением какой-нибудь экзотики вроде уже упомянутого F*
А как насчёт типизационных меток?
Не подскажете, что лучше почитать по Аде, чтобы было понятно и, желательно, на русском?
А то очень тяжело понимать, что там происходит в GNAT и в меню SPARK
Здравствуйте, FDSC, Вы писали:
FDS>·>Нет. Ты вопрос не понял. На каком основании компилятор будет решать, что "calculateHash" не должна писать в файл (и если кто-то случайно или намеренно там в файл пишет, то выдать ошибку компиляции), а "writeHash" может писать в файл? FDS>Программист явно укажет функции, которые могут писать в файл.
А calculateHash берёт ссылку на функцию, скажем, для преобразования charset. Каким образом ты объяснишь, что этот преобразователь не должен использовать файловый API? А если вдруг таблицу charset придётся таки в некоторых случаях читать из файла?
FDS>·>А если не все, а только 95% функций? А если 5%? Где границу-то ставить? FDS>Допустим у нас проект на 20 000 строк кода. 1000 тысяча строк кода может делать всё что угодно. Согласись, есть разница, сколько проверять?
Разница слабо коррелирует с кол-вом строк в общем случае.
FDS>·>Это гарантированно быстрее, чем делать много раз при удалении каждого объекта в программе. FDS>Гарантированно быстрее вообще не делать. FDS>Обнуление памяти при завершении процесса — это слишком рискованная операция. Обнулять всё должно очень и очень быстро.
Так это зависит от программы. Если прога держит большое кол-во в памяти в виде развесистой структуры, то может получиться гораздо быстрее занулить всё подряд, чем аккуратно вызывать деструкторы-занулители в правильном порядке.
FDS>>>Вдруг процесс, всё же, упадёт? FDS>·>Ты уж определись... FDS>Одно дело при краше не очистится память и мы не могли очистить, а другое дело, когда при краше можно очистить память, а мы всё равно не очистили.
С т.з. секьюрити невелика разница. Хакеры могут например специально убивать прогу в точно выбранные моменты времени.
FDS>·>Судя по спеке эта функция ничего не обещает по поводу того, что она не будет ничего никуда копировать. FDS>Что-то такое FDS>pwdAddress = VirtualAlloc(0, len, 0x1000 | 0x2000 | 0x00400000, 0x04);
И что эти цифири значат? Ты цитаты из док давай.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
