В Астре естественно готовы и внедрять и полноценно участвовать как в этом, так и во многих других, в том числе совместных, проектах. В ОС Astra Linux большинство СЗИ изначально внедряются на уровне ядра ОС, так что и соответствующие разработки уже давно ведутся.
Не совсем так. Говоря про уровни целостности в Windows лучше обратиться к статье Mandatory Integrity Control Mandatory Integrity Control (https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control). По умолчанию там уже используются не менее 7 различных уровней (https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids): SECURITY_MANDATORY_UNTRUSTED_RID, SECURITY_MANDATORY_LOW_RID и т.д. При этом администратор может задействовать в ряде случаев и промежуточные значения уровней, правда это редко где применяется, во многом из-за того, что удобнее всего использовать уже встроенные правила управления доступом вместо написания собственных политик. В этом плане встроенная реализация МКЦ в ОС Astra Linux обеспечивает достойную замену, а в ряде случаев предоставляет и более гибкие механизмы администрирования.
В том и преимущество, что средства защиты информации ОС Astra Linux работают "прозрачно" для пользователей и для большинства ПО, непрерывно обеспечивая все заложенные в них еще на этапе разработки ОС правила управления доступом (МКЦ, ЗПС, МРД и т.д.). Т.е вне зависимости от типа ПО и выполняемых им функций, его системные компоненты будут защищены от непреднамеренной модификации за счет обладания высоким мандатным уровнем целостности (МКЦ), а пользовательские данные сохранены и доступны только на соответствующем пользователю уровне конфиденциальности (МРД). Например, не важно, используете ли вы для редактирования файлов vim, nano, mcedit, kate или что-то еще и от имени какого пользователя вы это делаете - СЗИ отработают в любом случае одинаково на основе одних и тех же "вшитых" правил.
Контексты (политики) же SELinux (AppArmor), например, могут и задаются для каждого ПО отдельно (для AppArmor - профиль ПО, для SELinux - домены процессов и типы файлов, соответствующие данному ПО, если совсем упрощенно). При этом нет гарантий, что разработчик этого ПО или администратор действительно задал и задал вообще правильные правила в рамках данных контекстов (политик), что эти контексты непротиворечивы между собой и т.п, что приводит к ситуациям, представленным в скринах по ссылке в комментариях выше. И тут проблема даже больше не в том, что были излишне запрещены какие-то доступы, а наоборот - что в попытках избежать подобных ситуаций, были предоставлены чрезмерно высокие полномочия. Да и осуществлять поддержку систем, где используются политики, сконфигурированные на "свой вкус и лад" (при этом без гарантии корректности), куда сложнее...
Часть ответов дает комент ниже) По серверам - думаю, этот вопрос уже успешно решен.
В Астре естественно готовы и внедрять и полноценно участвовать как в этом, так и во многих других, в том числе совместных, проектах. В ОС Astra Linux большинство СЗИ изначально внедряются на уровне ядра ОС, так что и соответствующие разработки уже давно ведутся.
Да, начиная с применения штатного защитного преобразования данных и встроенных утилит шифрования, в том числе на основе ГОСТовых алгоритмов, заканчивая применением модулей доверенной загрузки и специализированных криптографических средств.
Плюс к этому, в основе ОС лежит не просто открытое общедоступное ядро Linux - для обеспечения качества и доверия к нему прилагаются немалые усилия со стороны отечественных специалистов.
Не совсем так. Говоря про уровни целостности в Windows лучше обратиться к статье Mandatory Integrity Control Mandatory Integrity Control (https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control). По умолчанию там уже используются не менее 7 различных уровней (https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids): SECURITY_MANDATORY_UNTRUSTED_RID, SECURITY_MANDATORY_LOW_RID и т.д. При этом администратор может задействовать в ряде случаев и промежуточные значения уровней, правда это редко где применяется, во многом из-за того, что удобнее всего использовать уже встроенные правила управления доступом вместо написания собственных политик. В этом плане встроенная реализация МКЦ в ОС Astra Linux обеспечивает достойную замену, а в ряде случаев предоставляет и более гибкие механизмы администрирования.
В том и преимущество, что средства защиты информации ОС Astra Linux работают "прозрачно" для пользователей и для большинства ПО, непрерывно обеспечивая все заложенные в них еще на этапе разработки ОС правила управления доступом (МКЦ, ЗПС, МРД и т.д.). Т.е вне зависимости от типа ПО и выполняемых им функций, его системные компоненты будут защищены от непреднамеренной модификации за счет обладания высоким мандатным уровнем целостности (МКЦ), а пользовательские данные сохранены и доступны только на соответствующем пользователю уровне конфиденциальности (МРД). Например, не важно, используете ли вы для редактирования файлов vim, nano, mcedit, kate или что-то еще и от имени какого пользователя вы это делаете - СЗИ отработают в любом случае одинаково на основе одних и тех же "вшитых" правил.
Контексты (политики) же SELinux (AppArmor), например, могут и задаются для каждого ПО отдельно (для AppArmor - профиль ПО, для SELinux - домены процессов и типы файлов, соответствующие данному ПО, если совсем упрощенно). При этом нет гарантий, что разработчик этого ПО или администратор действительно задал и задал вообще правильные правила в рамках данных контекстов (политик), что эти контексты непротиворечивы между собой и т.п, что приводит к ситуациям, представленным в скринах по ссылке в комментариях выше. И тут проблема даже больше не в том, что были излишне запрещены какие-то доступы, а наоборот - что в попытках избежать подобных ситуаций, были предоставлены чрезмерно высокие полномочия. Да и осуществлять поддержку систем, где используются политики, сконфигурированные на "свой вкус и лад" (при этом без гарантии корректности), куда сложнее...