✖


Jump to content

Linux с повышенной безопасностью

(Перенаправлено из SELinux )
SELinux
Оригинальный автор(ы) АНБ и Red Hat
Разработчик(и) Красная шляпа
Первоначальный выпуск 22 декабря 2000 г .; 23 года назад ( 22 декабря 2000 г. ) [1]
Стабильная версия
3.6 / 13 декабря 2023 г .; 6 месяцев назад ( 13.12.2023 ) [2]
Репозиторий
Написано в С
Операционная система Линукс
Тип Безопасность, модули безопасности Linux (LSM)
Лицензия GNU GPL
Веб-сайт Селинукспроект .org , https://www.nsa.gov/what-we-do/research/selinux/

Security-Enhanced Linux ( SELinux ) — это ядра Linux модуль безопасности , который обеспечивает механизм поддержки контроля доступа политик безопасности , включая обязательный контроль доступа (MAC).

SELinux — это набор модификаций ядра и инструментов пользовательского пространства, добавленных в различные дистрибутивы Linux . Его архитектура стремится отделить применение решений по безопасности от политики безопасности и оптимизирует объем программного обеспечения, задействованного в реализации политики безопасности. [3] [4] Ключевые концепции, лежащие в основе SELinux, можно проследить до нескольких более ранних проектов Агентства национальной безопасности США (АНБ).

Обзор [ править ]

Команда АНБ по усиленной безопасности Linux описывает SELinux АНБ как [5]

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

Ядро Linux, интегрирующее SELinux, применяет обязательные политики контроля доступа, которые ограничивают пользовательские программы и системные службы, а также доступ к файлам и сетевым ресурсам. Ограничение привилегий до минимума, необходимого для работы, уменьшает или устраняет возможность этих программ и демонов причинять вред в случае неисправности или компрометации (например, из-за переполнения буфера или неправильной конфигурации). Этот механизм ограничения работает независимо от традиционных механизмов контроля доступа Linux ( дискреционных ). Он не имеет понятия «корневого» суперпользователя и не разделяет хорошо известные недостатки традиционных механизмов безопасности Linux, такие как зависимость от двоичных файлов setuid / setgid .

Безопасность «немодифицированной» системы Linux (системы без SELinux) зависит от правильности ядра, всех привилегированных приложений и каждой из их конфигураций. Неисправность в любой из этих областей может привести к компрометации всей системы. Напротив, безопасность «модифицированной» системы (основанной на ядре SELinux) зависит в первую очередь от правильности ядра и конфигурации его политики безопасности. Хотя проблемы с корректностью или настройкой приложений могут привести к ограниченному взлому отдельных пользовательских программ и системных демонов, они не обязательно представляют угрозу безопасности других пользовательских программ и системных демонов или безопасности системы в целом.

С пуристской точки зрения, SELinux предоставляет гибрид концепций и возможностей, взятых из обязательного контроля доступа, обязательного контроля целостности , управления доступом на основе ролей (RBAC) и архитектуры соблюдения типов . Сторонние инструменты позволяют создавать различные политики безопасности.

История [ править ]

Самая ранняя работа, направленная на стандартизацию подхода, обеспечивающего обязательный и дискреционный контроль доступа (MAC и DAC) в вычислительной среде UNIX (точнее, POSIX), может быть отнесена к национальной безопасности рабочей группе Trusted UNIX (TRUSIX) Агентства , которая встретилась с 1987 по 1991 год и опубликовал одну «Радужную книгу» (# 020A), а также подготовил формальную модель и связанный с ней прототип оценочных данных (# 020B), которые в конечном итоге не были опубликованы.

SELinux был разработан, чтобы продемонстрировать сообществу Linux ценность обязательного контроля доступа и то, как такие элементы управления могут быть добавлены в Linux. Первоначально патчи, составляющие SELinux, должны были быть явно применены к исходному коду ядра Linux; SELinux был объединен с основной веткой ядра Linux в версии ядра Linux 2.6.

АНБ, первоначальный основной разработчик SELinux, выпустило первую версию для открытого исходного кода сообщества разработчиков под лицензией GNU GPL 22 декабря 2000 года. [6] Программное обеспечение было объединено с основным ядром Linux 2.6.0-test3, выпущенным 8 августа 2003 года. Среди других значительных участников — Red Hat , Network Associates , Secure Computing Corporation , Tresys Technology и Trusted Computer Solutions. Экспериментальные порты реализации FLASK /TE доступны через проект TrustedBSD для операционных систем FreeBSD и Darwin .

Linux с улучшенной безопасностью реализует ядро ​​расширенной безопасности Flux (FLASK). Такое ядро ​​содержит архитектурные компоненты, прототипы которых созданы в операционной системе Fluke . Они обеспечивают общую поддержку для применения многих видов политик обязательного контроля доступа, в том числе основанных на концепциях принудительного соблюдения типов , управления доступом на основе ролей и многоуровневой безопасности . на основе Mach FLASK, в свою очередь, был основан на DTOS, распределенной доверенной операционной системе , а также на Trusted Mach, исследовательском проекте компании Trusted Information Systems, оказавшем влияние на разработку и реализацию DTOS. [ нужна ссылка ]

Оригинальные и внешние участники [ править ]

Полный список первоначальных и внешних участников SELinux размещался на веб-сайте АНБ до прекращения его обслуживания где-то в 2009 году. Следующий список воспроизводит оригинал, сохраненный в Internet Archive Wayback Machine. Объем их вклада был указан на странице и опущен для краткости, но доступ к нему можно получить через архивную копию. [7]

  • Агентство национальной безопасности (АНБ)
  • Лаборатории Network Associates (NAI Labs)
  • Корпорация МИТЕР
  • Корпорация безопасных вычислений (SCC)
  • Мэтт Андерсон
  • Райан Бергауэр
  • Бастиан Бланк
  • Томас Блехер
  • Джошуа Бриндл
  • Рассел Кокер
  • Джон Деннис
  • Джанак Десаи
  • Ульрих Дреппер
  • Лоренцо Эрнандес Гарсия-Йерро
  • Даррел Гёддел
  • Карстен Громанн
  • Стив Грабб
  • Иван Гюрдиев
  • Серж Халлин
  • Чад Хэнсон
  • Йорг Хо
  • Трент Джагер
  • Дастин Киркланд
  • Кайгай Кохей
  • Пол Крумвиде
  • Джой Латтен
  • Том Лондон
  • Карл Макмиллан
  • Брайан Мэй
  • Фрэнк Майер
  • Тодд Миллер
  • Роланд МакГрат
  • Пол Мур
  • Джеймс Моррис
  • Юичи Накамура
  • Грег Норрис
  • Эрик Пэрис
  • Крис ПеБенито
  • Красная шляпа
  • Питер Родан
  • Шон Сэвидж
  • Чад Селлерс
  • Рохелио Серрано мл.
  • Джастин Смит
  • Руки Шривастава
  • Тресис Технология
  • Майкл Томпсон
  • Надежные компьютерные решения
  • Том Фогт
  • Рейно Валлин
  • И Уолш
  • Колин Уолтерс
  • Марк Вестерман
  • Дэвид А. Уилер
  • Венкат Йеккирала
  • Кэтрин Чжан

Пользователи, политики и контексты безопасности [ править ]

Пользователи и роли SELinux не обязательно должны быть связаны с реальными пользователями и ролями системы. Для каждого текущего пользователя или процесса SELinux назначает трехстрочный контекст, состоящий из имени пользователя, роли и домена (или типа). Эта система более гибкая, чем обычно требуется: как правило, большинство реальных пользователей используют одно и то же имя пользователя SELinux, а весь контроль доступа осуществляется через третий тег — домен. Обстоятельства, при которых процесс допускается в определенный домен, должны быть настроены в политиках. Команда runcon позволяет запустить процесс в явно указанном контексте (пользователе, роли и домене), но SELinux может запретить переход, если он не одобрен политикой.

Файлы, сетевые порты и другое оборудование также имеют контекст SELinux, состоящий из имени, роли (редко используемой) и типа. В случае файловых систем сопоставление между файлами и контекстами безопасности называется маркировкой. Маркировка определяется в файлах политики, но ее также можно настроить вручную, не меняя политики. Типы оборудования довольно подробно описаны, например, bin_t (все файлы в папке /bin) или postgresql_port_t (Порт PostgreSQL, 5432). Контекст SELinux для удаленной файловой системы можно указать явно во время монтирования.

SELinux добавляет -Z переключиться на команды оболочки ls, psи некоторые другие, позволяющие увидеть контекст безопасности файлов или процесса.

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

Типичная политика состоит из файла сопоставления (маркировки), файла правил и файла интерфейса, которые определяют переход домена. Эти три файла необходимо скомпилировать вместе с инструментами SELinux для создания единого файла политики. Полученный файл политики можно загрузить в ядро, чтобы сделать его активным. Загрузка и выгрузка политик не требует перезагрузки. Файлы политик либо написаны вручную, либо могут быть созданы с помощью более удобного для пользователя инструмента управления SELinux. Обычно они сначала проверяются в разрешительном режиме, когда нарушения регистрируются, но разрешаются. audit2allow Инструмент можно использовать позже для создания дополнительных правил, которые расширяют политику и позволяют ограничить все законные действия приложения.

Особенности [ править ]

Возможности SELinux включают в себя:

  • Четкое отделение политики от правоприменения
  • Четко определенные интерфейсы политики
  • Поддержка приложений, запрашивающих политику и обеспечивающих контроль доступа (например, запуск заданий crond в правильном контексте).
  • Независимость конкретной политики и политических языков
  • Независимость от конкретных форматов и содержания меток безопасности.
  • Отдельные метки и элементы управления для объектов и служб ядра.
  • Поддержка изменений политики
  • Отдельные меры защиты целостности системы (доменного типа) и конфиденциальности данных ( многоуровневая безопасность )
  • Гибкая политика
  • Контроль над инициализацией и наследованием процесса, а также выполнением программы.
  • Контроль над файловыми системами, каталогами, файлами и дескрипторами открытых файлов.
  • Управление сокетами, сообщениями и сетевыми интерфейсами.
  • Контроль над использованием «возможностей»
  • Кэшированная информация о решениях о доступе через кэш векторов доступа (AVC). [8]
  • Политика запрета по умолчанию (все, что явно не указано в политике, запрещено) [9] [10] [11]

Принятие [ править ]

sestatus показ статуса SELinux в системе

SELinux реализован в Android начиная с версии 4.3. [12]

Среди бесплатных дистрибутивов Linux, поддерживаемых сообществом, Fedora была одной из первых, кто внедрил ее, включая ее поддержку по умолчанию, начиная с Fedora Core 2. Другие дистрибутивы включают ее поддержку, например Debian, начиная с версии 9 Stretch. [13] и Ubuntu начиная с версии 8.04 Харди Херона. [14] Начиная с версии 11.1, openSUSE содержит «базовую поддержку» SELinux. [15] SUSE Linux Enterprise 11 представляет SELinux в качестве «предварительной версии технологии». [16]

SELinux популярен в системах на базе Linux-контейнеров , таких как CoreOS Container Linux и rkt. [17] Это полезно в качестве дополнительного элемента управления безопасностью, помогающего обеспечить изоляцию между развернутыми контейнерами и их хостом.

SELinux доступен с 2005 года как часть Red Hat Enterprise Linux (RHEL) версии 4 и всех последующих выпусков. Это присутствие также отражено в соответствующих версиях производных систем, таких как CentOS , Scientific Linux , AlmaLinux и Rocky Linux . Поддерживаемая политика в RHEL4 — это целевая политика, которая направлена ​​на максимальную простоту использования и, следовательно, не является такой ограничительной, как могла бы быть. Планируется, что в будущих версиях RHEL будет больше целей в целевой политике, что будет означать более ограничительные политики.

Сценарии использования [ править ]

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

Утилиты командной строки включают: [18] chcon, [19] restorecon, [20] restorecond, [21] runcon, [22] secon, [23] fixfiles, [24] setfiles, [25] load_policy, [26] booleans, [27] getsebool, [28] setsebool, [29] togglesebool[30] setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, [31] selinuxenabled, [32] и selinux-policy-upgrade[33]

Примеры [ править ]

Чтобы перевести SELinux в принудительном режиме:

setenforce 1

Чтобы запросить статус SELinux:

getenforce

Сравнение с AppArmor [ править ]

SELinux представляет собой один из нескольких возможных подходов к проблеме ограничения действий, которые может выполнять установленное программное обеспечение. Другая популярная альтернатива называется AppArmor и доступна на платформах SUSE Linux Enterprise Server (SLES), openSUSE и Debian . AppArmor был разработан как компонент ныне несуществующей платформы Immunix Linux . Поскольку AppArmor и SELinux радикально отличаются друг от друга, они представляют собой отдельные альтернативы для программного управления. В то время как SELinux заново изобретает некоторые концепции, чтобы обеспечить доступ к более выразительному набору вариантов политики, AppArmor был разработан как простой за счет расширения той же административной семантики, которая используется для DAC, до уровня обязательного контроля доступа.

Есть несколько ключевых отличий:

  • Одним из важных отличий является то, что AppArmor идентифицирует объекты файловой системы по имени пути, а не по индексному дескриптору. Это означает, что, например, файл, который недоступен, может стать доступным в AppArmor, когда на него будет создана жесткая ссылка, в то время как SELinux запретит доступ через вновь созданную жесткую ссылку.
  • SELinux и AppArmor также существенно различаются в способах администрирования и интеграции в систему. [34]
  • Поскольку AppArmor пытается воссоздать традиционные элементы управления DAC с применением уровня MAC, набор операций AppArmor также значительно меньше, чем те, которые доступны в большинстве реализаций SELinux. Например, набор операций AppArmor состоит из: чтения, записи, добавления, выполнения, блокировки и связывания. [35] Большинство реализаций SELinux будут поддерживать количество операций на порядки больше этого. Например, SELinux обычно поддерживает те же самые разрешения, но также включает элементы управления mknod, привязку к сетевым сокетам, неявное использование возможностей POSIX, загрузку и выгрузку модулей ядра, различные способы доступа к общей памяти и т. д.
  • В AppArmor нет элементов управления для категорического ограничения возможностей POSIX. Поскольку текущая реализация возможностей не содержит понятия субъекта операции (только актер и операция), обычно задачей уровня MAC является предотвращение привилегированных операций с файлами за пределами принудительной области управления актера (т. е. «песочницы»). ). AppArmor может предотвратить изменение своей собственной политики и запретить монтирование/размонтирование файловых систем, но не делает ничего, чтобы помешать пользователям выйти за пределы утвержденных ими сфер контроля.
    • Например, сотрудникам службы поддержки может быть полезно изменить владельца или разрешения для определенных файлов, даже если они ими не владеют (например, в общей файловой системе отдела). Администратор не хочет предоставлять пользователям root-доступ к ящику, поэтому они предоставляют им CAP_FOWNER или CAP_DAC_OVERRIDE. В SELinux администратор (или поставщик платформы) может настроить SELinux, чтобы запретить все возможности пользователям, которые в противном случае не были бы ограничены, а затем создать ограниченные домены, в которые сотрудник сможет перейти после входа в систему, и тот, который может использовать эти возможности, но только для файлов соответствующий тип. [ нужна ссылка ]
  • В AppArmor нет понятия многоуровневой безопасности, поэтому не существует жесткого обеспечения соблюдения BLP или Biba . [ нужна ссылка ] .
  • Конфигурация AppArmor выполняется исключительно с использованием обычных плоских файлов. SELinux (по умолчанию в большинстве реализаций) использует комбинацию плоских файлов (используемых администраторами и разработчиками для написания удобочитаемой политики перед ее компиляцией) и расширенных атрибутов.
  • SELinux поддерживает концепцию «удаленного сервера политик» (настраиваемого через /etc/selinux/semanage.conf) в качестве альтернативного источника для настройки политики. Централизованное управление AppArmor обычно значительно усложняется, поскольку администраторы должны выбирать между инструментами развертывания конфигурации, запускаемыми от имени пользователя root (чтобы разрешить обновление политик) или настраиваемыми вручную на каждом сервере.

Подобные системы и улучшения [ править ]

См. Также: Samsung Нокс

Изоляция процессов также может быть достигнута с помощью таких механизмов, как виртуализация ; проект OLPC , например, в его первой реализации [36] изолированные отдельные приложения на облегченных Vservers . Кроме того, АНБ приняло некоторые концепции SELinux в Android с улучшенной безопасностью . [37]

General Dynamics создает и распространяет доверенную операционную систему PitBull, [38] усовершенствование многоуровневой безопасности (MLS) для Red Hat Enterprise Linux .

Multi-Category Security (MCS) — это расширение SELinux для Red Hat Enterprise Linux , которое позволяет пользователям помечать файлы категориями, чтобы дополнительно ограничить доступ посредством дискреционного контроля доступа и принудительного применения типов. Категории предоставляют дополнительные отсеки внутри уровней чувствительности, используемых многоуровневой безопасностью (MLS). [39]

См. также [ править ]

Ссылки [ править ]

  1. ^ «Linux с повышенной безопасностью доступен на сайте АНБ — MARC» . МАРК . Проверено 24 декабря 2018 г.
  2. ^ «Выпуск пользовательского пространства SELinux 3.6» . Проект SELinux. 14 декабря 2023 г. Проверено 16 марта 2024 г.
  3. ^ «Часто задаваемые вопросы по SELinux (FAQ) — АНБ/CSS» . Агентство национальной безопасности. Архивировано из оригинала 18 сентября 2018 г. Проверено 6 февраля 2013 г.
  4. ^ Лоскокко, Питер; Смолли, Стивен (февраль 2001 г.). «Интеграция гибкой поддержки политик безопасности в операционную систему Linux» (PDF) .
  5. ^ «Linux с усиленной безопасностью — АНБ/CSS» . Агентство национальной безопасности. 15 января 2009 г. Архивировано из оригинала 22 октября 2020 г. Проверено 21 апреля 2021 г.
  6. ^ Сравнить «Агентство национальной безопасности делится улучшениями безопасности для Linux» . Пресс-релиз АНБ . Форт Джордж Г. Мид, Мэриленд: Центральная служба безопасности Агентства национальной безопасности. 02 января 2001 г. Архивировано из оригинала 18 сентября 2018 г. Проверено 21 апреля 2021 г. АНБ радо сообщить, что оно разработало и представляет общественности прототип версии операционной системы Linux с повышенной безопасностью.
  7. ^ «Участники SELinux» . Архивировано из оригинала 18 октября 2008 г.
  8. ^ Проект документации Fedora (2010). Руководство пользователя Linux с усиленной безопасностью Fedora 13 . Корпорация Фултус. п. 18. ISBN  978-1-59682-215-3 . Проверено 22 февраля 2012 г. Решения SELinux, такие как разрешение или запрет доступа, кэшируются. Этот кэш известен как кэш векторов доступа (AVC). Решения о кэшировании уменьшают частоту проверки правил SELinux, что повышает производительность.
  9. ^ «SELinux/Краткое введение — Gentoo Wiki» . wiki.gentoo.org .
  10. ^ «Начало работы с SELinux» . Руководства и учебные пособия Linode .
  11. ^ «Обзор NB — SELinux Wiki» . selinuxproject.org .
  12. ^ «Linux с повышенной безопасностью в Android» . Проект Android с открытым исходным кодом . Проверено 31 января 2016 г.
  13. ^ «СЕЛинукс» . debian.org .
  14. ^ «Как установить SELinux в Ubuntu 8.04 «Hardy Heron» » . Учебники по Ubuntu .
  15. ^ «Новости openSUSE» . 20 августа 2008 г.
  16. ^ «Примечания к выпуску SUSE Linux Enterprise Desktop 11» . Новелл . Проверено 6 февраля 2013 г.
  17. ^ «SELinux на CoreOS» . Документация по CoreOS .
  18. ^ «SELinux/Команды — FedoraProject» . Проверено 25 ноября 2015 г.
  19. ^ "чкон" . Linuxcommand.org. Архивировано из оригинала 24 октября 2004 г. Проверено 6 февраля 2013 г.
  20. ^ «restorecon(8) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  21. ^ «restorecond(8) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  22. ^ «runcon(1) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  23. ^ «secon(1) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  24. ^ «fixfiles(8): исправить контексты безопасности файла SELinux — страница руководства Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  25. ^ «setfiles(8): установить контексты безопасности файла SELinux — страница руководства Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  26. ^ «load_policy(8) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  27. ^ «booleans(8) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  28. ^ «getsebool(8): логическое значение SELinux — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  29. ^ «setsebool(8): установить логическое значение SELinux — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  30. ^ «togglesebool(8) — справочная страница Linux» . Linux.die.net . Проверено 6 февраля 2013 г.
  31. ^ «Страница руководства Ubuntu: selinux-config-enforcing — измените /etc/selinux/config, чтобы установить принудительное применение» . ООО "Каноникал " Архивировано из оригинала 20 декабря 2012 г. Проверено 6 февраля 2013 г.
  32. ^ «Страница руководства Ubuntu: selinuxenabled — инструмент, который будет использоваться в сценариях оболочки, чтобы определить, есть ли» . ООО "Каноникал " Архивировано из оригинала 9 февраля 2013 г. Проверено 6 февраля 2013 г.
  33. ^ «Страница руководства Ubuntu: selinux-policy-upgrade — обновить модули в политике SE Linux» . ООО "Каноникал " Архивировано из оригинала 4 апреля 2012 г. Проверено 6 февраля 2013 г.
  34. ^ «Фоны SELinux» . SELinux . Руководство по безопасности. СУЗЕ.
  35. ^ «apparmor.d — синтаксис профилей безопасности для AppArmor» . Архивировано из оригинала 17 октября 2013 г.
  36. ^ «Радуга» . Ноутбук.org .
  37. ^ «Работы, связанные с SELinux» . АНБ.gov . Архивировано из оригинала 20 февраля 2018 г. Проверено 23 августа 2016 г.
  38. ^ Общая динамика. «Надежная операционная система PitBull» .
  39. ^ Red Hat, Inc. «49.4. Многокатегорийная безопасность (MCS)» .

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Security-Enhanced_Linux&oldid=1226700155"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 570321b47867f00cf7111f8211755ba4__1717220520
URL1:https://arc.ask3.ru/arc/aa/57/a4/570321b47867f00cf7111f8211755ba4.html
Заголовок, (Title) документа по адресу, URL1:
Security-Enhanced Linux - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)