没有没有漏洞的操作系统-唯一的问题是开发人员如何有效地识别并关闭它们。 我们的Astra Linux特别版操作系统也不例外：我们会不断检查并测试代码中的错误，逻辑违规，其他错误，并迅速对其进行修复。 否则，俄罗斯的FSTEC几乎不会通过Astra Linux认证来处理构成国家机密的数据。 但是，我们将在另一篇文章中更详细地讨论认证。 在本文中，我们将讨论如何组织Astra Linux漏洞以及如何将信息安全威胁与本地数据库进行交互。
照片：Leonhard Foeger /路透社第一种方法，建筑
为了提高操作系统的安全性，我们使用两种方法。 首先是
体系结构 ，是我们在设计阶段开发并实现各种信息保护工具。 这些工具形成了
保护设备（KSZ）的
复合体，这些
设备执行安全功能。 在KSZ的帮助下，我们试图确保系统默认情况下已将潜在威胁的风险降至最低。
Astra LInux特别版安全套件架构呼叫监视器是KSZ的关键要素，旨在防止未经授权的访问和更改系统受保护组件。 该监视器提供了基于角色的自由访问，强制访问控制以及强制完整性监视。
什么是
强制性完整性监视 ？ 让我们举例说明。 操作系统的关键组件是内核。 因此，我们有义务在操作系统本身中为其提供最安全的运行时，以减少攻击内核的可能方法。
为此，我们在操作系统中实施了强制性完整性监控，因此，我们通过各种子系统对OS进行了划分，因此破坏一个子系统不会影响其他子系统的性能。 如果操作系统（完整性级别0）或网络子系统（完整性级别1），虚拟化系统（完整性级别2），图形界面（完整性级别8）或其他组件的非特权用户被黑客入侵，则这不会导致整个KSZ（完整性级别）的信誉下降。 63）。
应当注意，这些级别不是分层的，也就是说，它们不位于彼此之上，并且就写权限的可能性而言是彼此完全隔离的。 访问监视器通过位掩码将对象的附件确定为一个或另一个完整性级别。
这样就不会将完整性级别视为层次结构，也就是说，例如“级别8的权限比级别2的权限更多”，这是错误的，每个级别都有其名称。 例如，第八个完整性级别称为“图形服务器”，系统中管理员的最大可能完整性级别为“高”，而零完整性级别（用户）为“低”。
呼叫监控器（在我们之前的
文章中已进行了介绍）通过使用具有不同完整性级别的标签来控制并消除了相互影响的可能性。
因此，操作系统接收到有关如何将系统进程彼此隔离的一组规则，并且现在可以了解哪些进程，即使是由具有高特权的用户启动的进程，也无权写入其他进程或文件。
因此，如果由于利用漏洞（包括零日）而导致攻击者获得了对系统中进程的控制权，并且增加了对特权用户（例如root）的权限，则其完整性标记将保持不变，因此，他将不会收到影响系统进程，更改设置或隐藏您在系统中的状态的能力。
隔离完整性级别的操作原理因此，并不是整个操作系统都成为攻击者的重要目标，而是硬化的内核和最紧凑的访问监视器，这已经大大减少了攻击面。
除了强制性之外，还存在动态和监管完整性控制。 它们用于排除不信任或第三方软件的启动和使用，以及系统完整性的定期检查。
动态控制在可执行文件启动时计算并验证可执行文件的电子数字签名。 如果没有EDS或它不正确，则将拒绝启动程序。 在某种程度上，这是白名单概念的实现，但使用的是发布给软件开发人员的密钥层次结构。
使用动态完整性控制例行控制通过将密钥文件的校验和与参考值进行比较，来检查系统密钥文件的完整性和不变性。 它可以是配置文件，也可以是任何其他文件。
因此，操作系统使用分层保护来抵御应用程序中的漏洞及其替代，从而将安全威胁（包括使用零时差漏洞的安全威胁）的损失降到最低。
第二，过程方法
与体系结构一起，我们同时使用
过程方法：我们不断识别和收集有关漏洞的信息，通过这些信息进行工作，并将结果传输到FSTEC Russia漏洞数据库。 因此，我们准备并发布计划的和可操作的操作系统更新。 我们正在寻找开放源代码中和独立存在的漏洞-尤其是在我们完全自行开发的软件部分中。 我们从从事类似研究（测试和研究操作系统安全性）的合作伙伴那里获得了大量信息。
漏洞管理安全性研究主要是针对Astra Linux特别版（Smolensk）中的组件进行的。 同时，作为安全更新的一部分和系统组件的预定更新的一部分，Astra Linux Common Edition的漏洞也已关闭。
收到有关漏洞的信息后，我们将立即检查该漏洞与我们的用户的相关性。
如果该漏洞不是很严重，那么我们将在下一版官方网站
的安全公告中对其进行描述。 通过电子邮件将有关投票问题的通知发送给用户，该地址必须在许可协议中指明。
对于严重漏洞，指南在几天内发布 ：如何独自解决问题而又不等待累积的安全更新。 在安全公告
列表中 ，它们标记有字母MD（方法方向）。
漏洞是一个很好的例子，有关此问题的信息
已在此处
发布在Habré上。 顺便说一句，本文的作者没有提前与我们联系，也没有事先通知他已经确定了此漏洞并正在准备材料。 作为说明，我们决定从该文本发布到资源中开始就引用该漏洞的工作时间。
因此，在2019年7月9日凌晨4点，文章本身已经发布，指出在操纵虚拟机的屏幕尺寸时，您可以看到屏幕锁下方的窗口。
值得注意的是，为了利用视频中展示的漏洞，您需要执行一些其他步骤：您必须首先在Astra Linux虚拟机上安装其他软件包，然后在来宾计算机上安装这些软件包，这些软件包负责实时更改虚拟机的分辨率，但不能是经过认证的操作系统的一部分。
2019年7月10日，漏洞信息在FSTEC BDU中发布。 漏洞的严重程度定义为中（CVSS 2.0指标的基本得分为4.9，CVSS 3.0指标的基本得分为4）。
7月12日，我们发布了Astra Linux特别版1.6版的安全公告
20190712SE16MD和Astra Linux特别版1.5版的安全公告
20190712SE15MD 。 Astra Linux Common Edition收到了类似的安全更新。
因此，自从有关中级漏洞的信息发布以来，不到4天就为所有版本的Astra Linux（可以进行虚拟化）发布了补丁。
Astra Linux的实时更新方案我们至少每季度发布一次安全更新-可以消除以前未知的漏洞（包括未实现安全要求的应用软件，库和OS功能）的
运营更新 。 如果不能通过补偿措施排除使用此漏洞实施的安全威胁，则正在努力完成操作系统的定稿。 在完成安全更新的开发和测试之后，该网站还将发布新闻通讯和更新本身。 在2019年的前六个月中，发布了针对Astra Linux特别版1.6版的两个累积更新，涵盖了数百个不同的漏洞。 现在，第三个正在准备发布。
最后，我们正在与开发人员社区积极互动：
- 我们在项目Bugtrackers中通知自我检测到的错误；
- 我们将现成的缺陷改正项目移交到项目中，由我们关闭；
- 我们呼吁社区协助消除缺陷-程序逻辑的知识使您比自己进行逆向工程的校正速度快一个数量级；
- 我们使用并在更新中包含所有社区发布的修补程序。 我们了解这可以提高产品质量。 同时，我们应用了上一篇文章中描述的控制和建立信任的方法。
开放性很重要
由于我们的操作系统已通过俄罗斯FSTEC的认证，因此我们首先添加有关在FSTEC信息安全威胁数据库（DBU）中发现的漏洞的信息以供正式发布：如果您访问
DBU ，则将在不同版本的Astra Linux中找到有关350多个固定漏洞的信息。以及有关它们的详细信息。
因此，我们确保工作的开放性。 因此，包括调节器在内的用户可以在一定程度上确信安全性确实受到控制。 仅获得更新还不够，您需要了解它关闭了哪些特定漏洞。
到目前为止，我们维护操作系统安全性的体系结构和过程方法是完全合理的-我们使用Astra Linux Special Edition OS成功地为信息系统维护了高级别的安全性。 通过FSTEC控制面板公开访问有关漏洞的信息可以提高对我们产品的信任度。
我们很乐意在评论中回答有关我们系统安全性的问题。 另外，如果您有兴趣学习有关该系统的新知识，请保留您的愿望-在进一步处理博客时，我们会考虑它们。