Новая версия Astra Linux Common Edition 2.12.29

Ключевая ошибка внедренцев сисетГ - это насилие и отсутствие свободы выбора, которое они устроили в Debian и других дистрах.

Свободное комьюнити такое не потерпит. Достаточно было в несвободных организациях выпустить приказы о принудительной установке и использовании системГ, но ведь они устроили практически геноцид остальным инит системам. А почему? - а потому что системD - это 5% инита и 95 процентов другого шита.

Только зачем всё это? CE и так бесплатна для физ.лиц

Её нельзя продавать и распространять.

Ключевая ошибка внедренцев сисетГ - это насилие и отсутствие свободы выбора, которое они устроили в Debian и других дистрах.

На опеннете майором угрожают за такие слова. Пруф в комментах сабжевой новости.

На опеннете майором угрожают за такие слова.

А какое обоснование? Их можно за такие угрозы засудить?

Какой там Дебиан, по-прежнему 9?

Сам почитай https://www.opennet.ru/opennews/art.shtml?num=52955

учитывая что больше чем половина пользователей тут в астру вообще нефортепьян, скажу, планшетный вариант у них очень зачётный

Вот с этого места поподробнее.

Ключевая ошибка внедренцев сисетГ - это насилие и отсутствие свободы выбора, которое они устроили в Debian и других дистрах.

Ключевая ошибка была в том, что они в качестве основного аргумента «за» приводили скорость загрузки, хотя это было самым незначительным нововведением. То есть там по факту удаляли раковую опухоль на теле юникс-систем в виде тысяч абсолютно одинаковых по своей сути init-скриптов с кучей дублирующегося кода, возникшую потому что 40 лет назад кто-то сделал костыль для запуска процессов помимо тех, которые прописаны в /etc/inittab. Вот пример с одной системы под debian:

$ grep 'case "$1" in' /etc/init.d/ -R|wc -l
82

то есть там на полном серьёзе 82 файла примерно одной структуры:

. /etc/default/$servicename
case "$1" in 
 start)
   $servicename & 
 ;;
 stop)
   kill -9 `pidof $servicename`
 ;;
 *)
   echo "Usage: /etc/init.d/nmbd {start|stop|restart|force-reload|status}"
 ;;
esac 

Второй ошибкой было то, что не было принято достаточно жёсткое решение по миграции дистрибутивов, то есть в том же debian 8 была поддержка обеих систем инициализации параллельно. В итоге получалось примерно следующее: есть инитскрипты и юниты для одного и того же сервиса, при загрузке с systemd было вообще непонятно, как именно запускается сервис.

kill -9 `pidof $servicename`

Прям тебя послушаешь, все 72 сервиса так убиваются. А по факту в юнитах вот такое наворачивают:

ExecStart=/usr/lib/virtualbox/vboxdrv.sh start
ExecStop=/usr/lib/virtualbox/vboxdrv.sh stop

За что боролись спрашивается?

Ну это отдельный вид извращения, да. Надеюсь рано или поздно это окончательно искоренят в linux

Ключевая ошибка была в том, что они в качестве основного аргумента «за» приводили скорость загрузки, хотя это было самым незначительным нововведением. То есть там по факту удаляли раковую опухоль на теле юникс-систем в виде тысяч абсолютно одинаковых по своей сути init-скриптов с кучей дублирующегося кода, возникшую потому что 40 лет назад кто-то сделал костыль для запуска процессов помимо тех, которые прописаны в /etc/inittab. Вот пример с одной системы под debian:

Ты приводишь преимущества всего лишь 5% systemD, которые действительно относятся к init, но тебе пытаются объяснить, что в systemD еще целая куча говна - остальные 95%, которые к инициализации вообще никаким местом не относятся.

OpenRC - это как 5% полезного кода systemD, но без каких-либо добавок в виде дополнительных 95% кучи говна в подарок.

OpenRC - это как 5% полезного кода systemD, но без каких-либо добавок в виде дополнительных 95% кучи говна в подарок.

Да, от case $1 in они избавились, но порождаемые процессы они всё так же не могут трекать, поэтому используют костыль start-stop-daemon, хотя даже sysvinit умел трекать порождаемые им процессы:

#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Проблема в systemd vs !systemd в том, что остальные шли на полумеры и решали только одну из проблем sysvinit. Если же говорить про остальные компоненты помимо управления сервисами, некоторые из них давно требовалось переписать. Я могу критиковать конкретные реализации, но идеологически они делают всё верно, этот нарыв на теле пингвина давно надо было всковырнуть.

Там есть бэкдоры от ФСБ?

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

По той ссылке лично я вижу нормальный текст в цитате и никак не вытекающий из него ответ «Встретимся в суде!». Это ж не человек из Астры про суд заговорил, а кто-то вбросил.

Не волнуйтесь, конечно есть.

Лицензию их читай. Изменять дистрибутив ты не можешь.

Вам чё, заняться больше нечем? Выяснять, каким образом у вас оказалась во рту малиновая косточка, если вы не ели малину?😂😂😂😂👼

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

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

Речь о плохопроверенной «безопасности» Астры, а не об идейности, проприетарный код - это не про безопасность системы, а про безопасность доходов разработчика в ущерб безопасности системы.

не печёт (с)

Подожди, какой код Астры, выше ведь написали, что в ней только обои от Дебиана поменяли?

Ты коду Дебиана не доверяешь?

Подожди, какой код Астры, выше ведь написали, что в ней только обои от Дебиана поменяли?

Так то в CE, а речь про закрытый код SE.

Ты коду Дебиана не доверяешь?

В Debian есть закрытый код, без которого он не может работать?

то есть СЕ мы доверяем? А SE - нет?

Astra Linux Anonymous Edition

Astra Linux ZverCD :)

то есть СЕ мы доверяем? А SE - нет?

косишь под дэбила?

CE можно проверить независимым экспертом, а SE нельзя

почему ты не хлопаешь тогда в ладоши, ведь новость которую ты комментишь, как раз про СЕ - новая версия вышла. С новым софтом.

CE можно проверить независимым экспертом, а SE нельзя

В этом планет нет разницы CE или SE

почему ты не хлопаешь тогда в ладоши, ведь новость которую ты комментишь, как раз про СЕ - новая версия вышла. С новым софтом.

1. Зачем мне ось с systemD? в нее опасно засовывать даже свой Rutoken. В SE впрочем тоже, потому что она еще хуже, чем CE, с точки зрения отсутствия возможности независимого аудита ее сорцов.

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

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

В этом планет нет разницы CE или SE

И как проверить сорцы SE независимым экспертом, отличным от ФСТЭК?

Обратиться к разработчику, оформить NDA -> получить исходники

ващет сорцы проверяет не ФСТЭК, а испытательная лаборатория и готовит заключение по итогу проверки, на основании которого ФСТЭК потом выдает сертификат

Обратиться к разработчику, оформить NDA -> получить исходники

Об этом где-то заявлено официально?

ващет сорцы проверяет не ФСТЭК, а испытательная лаборатория и готовит заключение по итогу проверки, на основании которого ФСТЭК потом выдает сертификат

Суть вопроса была в возможности свободы выбора эксперта, а не навязанности какого-либо определенного кем-либо не ради легитимности ЭЦП в суде, а ради проверки реальной защищенности системы по каким-то своим критериям.

Об этом где-то заявлено официально?

А какой смысл? Те кто хочет проверить сами придут. А остальные только «языком болтать умеют»

А какой смысл?

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

Те кто хочет проверить сами придут. А остальные только «языком болтать умеют»

Однако на форуме многие уверенны, что код SE проприетарен и недоступен. Какие условия NDA?

а как ты меряешь защищенность ОС?

по отсутствию CVE? или по реализованным технологиям защиты?

Тут на форуме кто-то есть со звездами от производителя Астра?

Могут подтвердить предоставление сорцов SE под NDA? Какие условия?

а как ты меряешь защищенность ОС?

В первую очередь по возможности получить сорцы.

значит, gNewSense самый защищенный дистрибутив Linux?

ты точно не путаешь доверие с защищенностью?

значит, gNewSense самый защищенный дистрибутив Linux?

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

Например, GH INTEGRITY соответствует как критерию предоставления сорцов, так и критериям безопасности.

Или другой пример, когда говорят, что главное, чтобы работа была интересная, это не значит, что нет других критериев. Вторым критерием идет уровень оплаты не ниже определенного в час, например, если в месяц получается $600 USD, то это значит, что больше 20 часов в месяц работать нежелательно. Но это не отменяет и то, что за $100/h можно даже заняться какой-то неинтересной херью в течение нескольких недель подряд, чтобы потом целый год заниматься только по критерию интересности.

ты говоришь о доверии к закрытому коду, которое очевидно никогда не может быть 100% по очевидным причинам.

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

посмотри, примерно, как это реализуется: https://www.youtube.com/watch?v=A5wd_Dg9rNQ

ты точно не путаешь доверие с защищенностью?

Тут уже многие высказывали свое недоверие лабораториям ФСТЭК, поэтому нет смысла доверять ФСТЭК в плане защищенности системы.

Разве можно доверять свою безопасность системе, которую проверяла недоверенная за пределами суда РФ организация?

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

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

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

При наличии троянов в дистрибутиве такая защищенность иллюзорная, она что есть, что нет - почти без разницы.

ну то есть по-твоему, условием выдачи сертификата на ОС на право работать с гостайной особой важности является обязательное наличие троянов и бэкдоров в системе?

ну при этом мы же помним, что в Астре не применяется шифрование как класс, для защиты информации, да ведь?

Устанавливайте на здоровье. Для физических лиц использование не требует приобретение лицензий.

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

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

ну то есть по-твоему, условием выдачи сертификата на ОС на право работать с гостайной особой важности является обязательное наличие троянов и бэкдоров в системе?

Это какая-то НЛП заготовка? Столько смыслов перепутано в одном предложении.

1. Из того, что эксперт не нашел или проигнорировал наличие троянов, не следует их отсутствие.

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

ну так государство потому и требует 100% исходников при проведении испытаний, прежде чем дать разрешение на право работы с гостайной, как раз, что бы доверять и убедиться в отсутствии закладок и троянов.