Рис. 1. Архитектура операционной системы «Феникс»
Стремительная информатизация привела к необходимости применения современных компьютерных технологий в областях, где одним из основных требований является безопасность, что привело к появлению проблемы создания защищенных систем обработки информации. Отечественная специфика этой проблемы состоит в том, что процесс внедрения компьютерных средств обработки информации и их защита осуществляются одновременно, например, разработка отечественных стандартов и критериев безопасности идет параллельно с применением имеющихся на рынке импортных средств и технологий, а также с разработкой собственных средств защиты. В данной статье пойдет речь об одной из отечественных разработок — защищенной ОС «Феникс» (не путать с китайской под Android).
Обеспечение информационной безопасности невозможно без применения отечественных разработок, однако, нельзя (да и не нужно) изолировать эту сферу деятельности от общего прогресса — следует соблюдать баланс между необходимостью поддержания безопасности критических систем с помощью специальных средств отечественной разработки и стремлением (а зачастую и необходимостью) использовать мировые достижения в области информационных технологий. Сегодня перед отечественными разработчиками средств защиты стоят две противоречивые задачи:
Основное противоречие состоит в том, что требование совместимости с популярными импортными средствами подразумевает их использование в составе защищенной системы, что не позволяет в полной мере реализовать предъявляемые требования, поскольку эти средства не рассчитаны на работу в составе систем, критичных к безопасности. Разработчики большинства популярных приложений не ставили перед собой такой задачи в силу изначальной ориентации этих продуктов на массовый рынок средств автоматизации. Действительно, ни один из популярных продуктов не рассчитан на решение задач, связанных с обеспечением безопасности, о чем свидетельствует отсутствие сертификации этих продуктов в западных странах в работоспособной конфигурации. Практически все системы общего назначения, получившие за рубежом сертификаты безопасности, — это специальные защищенные версии Unix типа CX/SX Harris Computer Systems, HP-UX BLS Hewlett Packard, Trusted IRIX/B SGI и т.д. Область применения подобных систем в нашей стране ограничена дорогой эксклюзивной аппаратной платформой, да и сама возможность поставки защищенных версий таких систем вызывает ряд вопросов. Наиболее распространенные у нас продукты Microsoft и Novell никогда не были нацелены на рынок защищенных систем и не получали сертификатов выше C2 по «Оранжевой книге». Следовательно, работа с категорированной информацией в системах такого уровня недопустима. Поэтому отечественный потребитель, нуждающийся в средствах работы с закрытой информацией, в полной мере является заложником ситуации, сложившейся на рынке программных средств, и вынужден искать частные или половинчатые решения.
Специфика построения защищенных систем обработки информации сегодня состоит в том, что в силу тотального господства на отечественном и мировом рынке средств, исходно практически лишенных свойств безопасности, встраивание в них дополнительных средств защиты — занятие безнадежное, особенно в условиях отсутствия исходных текстов и соответствующей поддержки со стороны производителей. С другой стороны реальность такова, что любые попытки построения систем защиты, не совместимых с популярными средствами обработки информации, заранее обречены на неудачу. Единственный выход — создание отечественной защищенной операционной системы, обеспечивающей безопасность обрабатываемой информации в соответствии с самыми строгими требованиями отечественных и мировых стандартов, но рассчитанной на использование совместно с существующими системами и приложениями в таком виде, в каком они есть, без изменений и доработок.
Данный подход к решению задачи построения защищенных систем обработки информации реализуется в Специализированном центре защиты информации Санкт-Петербургского государственного технического университета (СЦЗИ СПбГТУ), а результатом стала операционная система Феникс, которая исходно создавалась как специальная защищенная операционная система класса Unix, отвечающая отечественным требованиями и стандартам информационной безопасности. Разработке этой ОС предшествовали многочисленные исследования в области анализа механизмов нарушения безопасности [1], выявления источников уязвимостей [2], разработки моделей безопасности, инвариантных к видам взаимодействий [3,4] и методов реализации контроля доступа в операционных системах [5].
Операционная система представляет собой микроядерную, многопользовательскую, многозадачную, многопоточную операционную систему класса UNIX со встроенными механизмами защиты, обеспечивающими контроль взаимодействий, управление доступом, контроль целостности, идентификацию/аутентификацию пользователей и возможность подключения средств шифрования.
Микроядерная архитектура отвечает принципу интегрированности, поскольку только в микроядерных системах для взаимодействий используется единственный способ — обмен сообщениями. Контроль доступа органично встраивается в этот механизм, причем, установив тотальный контроль над потоками сообщений, можно быть уверенным в том, что контролируются все взаимодействия в системе.
Принцип инвариантности определил организацию всех взаимодействий в «Феникс» на основе архитектуры клиент-сервер. Все компоненты выступают в качестве серверов, предоставляющих свои ресурсы другим компонентам, и, в свою очередь, являются клиентами по отношению к другим серверам. Соответственно субъектом взаимодействия всегда является клиент, а объектом — ресурс, поддерживаемый сервером. Таким образом, достигается абстрагирование системы защиты от специфики взаимодействий, но в то же время сохраняется ее гибкость. Контроль и управление доступом могут быть реализованы как на уровне всей системы в целом, так и в составе серверов, обслуживающих ресурсы, что позволяет при необходимости реализовать в серверах специализированные механизмы защиты, адаптированные к специфике обслуживаемых ими ресурсов.
В соответствии с принципом унификации доступ к объектам в «Феникс» осуществляется через УНифицированный Интерфейс Доступа к Объектам (УНИДО), определяющий множество операций, универсальных для всех типов объектов, в виде универсального набора методов, позволяющего выполнять все операции доступа к объектам, их создания и уничтожения, управления их свойствами. Использование УНИДО единственный способ выполнения операций над объектами в «Феникс». Интерфейс оформлен в виде абстрактного класса, от которого наследуются интерфейсы всех серверов «Феникс», реализуемых УНИДО. Наличие набора типовых операций упрощает реализацию контроля доступа, поскольку определено однозначное соответствие между методами УНИДО и операциями доступа, описываемыми моделями безопасности. Кроме того, применение объектно-ориентированной технологии программирования облегчает разработку и расширение возможностей средств защиты.
В соответствии с принципом адекватности архитектура «Феникс» построена таким образом, что контроль и управление доступом осуществляются на основе единой модели представления ресурсов в виде иерархии объектов, доступ к которым осуществляется посредством УНИДО. Такая архитектура не допускает появления привилегированных средств и исключений из общих правил. В состав подсистемы контроля доступа входят всего две процедуры: реализованная в микроядре функция передачи сообщений и специальный монитор взаимодействий, контролирующий доступ к объектам системы. Таким образом, объем программ, корректность функционирования которых критична для безопасности всей системы, сокращен до минимума, поскольку средства контроля являются универсальными для всех видов взаимодействий и типов объектов. Достигнутая с помощью этих решений простота и компактность средств контроля способствует применению формальных методов верификации и анализа программного кода.
Контроль и управление доступом в «Феникс», согласно принципа корректности, реализованы на основе дискреционно-ролевой и принудительной моделей управления доступом. Однако, благодаря инвариантности средств контроля доступа и унификации операций УНИДО, в «Феникс» допускается применение любых моделей безопасности, основанных на контроле взаимодействий субъектов и объектов и управлении атрибутами безопасности. Феникс допускает внедрение новых моделей безопасности без изменения микроядра и средств контроля, причем возможно как независимое применение нескольких моделей для различных подмножеств пространства объектов, так и совместное использование моделей (например, комбинации избирательной и принудительной моделей).
|
Рис. 1. Архитектура операционной системы «Феникс» |
В состав «Феникс» входят следующие компоненты (рис. 1): микроядро, базовые службы, средства защиты, системные службы, прикладные службы, приложения ОС «Феникс», а также набор административных средств, функционирующих в среде Windows и осуществляющих удаленное взаимодействие с «Феникс». Система разрабатывалась как защищенная платформа, поэтому набор приложений минимизирован и состоит из стандартных утилит Unix и специальных средств управления безопасностью.
Микроядро осуществляет управление процессами и распределением памяти, реализует обмен сообщениями, обеспечивает изоляцию адресных пространств процессов, контролирует распределение аппаратных ресурсов. Функции микроядра сокращены до минимума и, в отличие от других микроядерных систем, микроядро «Феникс» не поддерживает высокоуровневых объектов. Основная функция микроядра — организация взаимодействия компонентов с помощью обмена сообщениями, единственного механизма позволяющего осуществлять обмен данными между абсолютно изолированными адресными пространствами процессов. Микроядро обеспечивает гарантированную доставку сообщений, достоверность источника и получателя сообщения, невозможность перехвата, повторной передачи и подделки сообщений.
Все остальные функциональные возможности ОС реализованы за пределами микроядра в виде отдельных, полностью изолированных процессов-серверов, поддерживающих пространство объектов, доступ к которым возможен только через УНИДО. Микроядро и одна из базовых служб, отвечающая за поддержку глобального пространства имен, обеспечивают уникальные имена объектов и их идентификацию. Каждый сервер поддерживает определенное подмножество объектов и выполняет операции над ними по запросам других процессов. Каждый объект имеет определенный тип и уникальный общесистемный идентификатор. Сервер может поддерживать объекты различных типов. Множество допустимых операций над объектами определяется типом объекта.
Реализация контроля доступа за пределами микроядра позволила сделать микроядро и службы независимыми от модели безопасности. В результате мы имеем разделение функций между различными компонентами: микроядро обеспечивает передачу запросов от клиентов к серверам, серверы реализуют обработку запросов, а управление доступом осуществляется монитором взаимодействий.
Особым подклассом базовых служб являются аппаратные драйверы, поскольку только для них микроядро разрешает доступ к аппаратным ресурсам — портам, прерываниям, физической памяти. Драйверы отображают аппаратные ресурсы в объекты «Феникс», которые используются другими службами, не имеющими непосредственного доступа к аппаратуре. Таким образом, только драйверы и микроядро «Феникс» являются аппаратно-зависимыми компонентами, причем реализация микроядра зависит только от механизмов процессора, отвечающих за управления виртуальной памятью и разделения адресных пространств. Остальные службы не содержат аппаратно-зависимого кода.
Основой средств защиты является монитор взаимодействий — специальный компонент, работающий в связке с ядром и осуществляющий контроль взаимодействий в соответствии с политикой безопасности и поставляющий информацию для протокола аудита. Контроль взаимодействий осуществляется следующим образом:
Такое разделение средств обработки и средств защиты обеспечивает гибкость механизмов управления доступом. Изменение моделей управления доступом или внедрение новых моделей не требует изменений микроядра или функциональных служб.
Поскольку монитор взаимодействий не реализует никакой модели безопасности, а только контролирует операции УНИДО, для принятия решения о доступе он взаимодействует со специальным набором компонентов, обеспечивающих возможность реализации любой модели безопасности, основанной на отношениях субъект-объект и атрибутах безопасности. Это группа служб, которые хранят атрибуты безопасности субъектов и объектов, правила контроля и управления доступом, учетные записи пользователей и другую информацию, необходимую для принятия решения о доступе в соответствии с правилами модели безопасности. Например, одна из этих служб обеспечивает независимое от конкретной модели хранение атрибутов безопасности в специальной базе, размещенной на специальной файловой системе. Эти службы вместе с монитором взаимодействий со службами аутентификации, аудита и контроля целостности полностью изолированы от остальных компонентов ОС и могут взаимодействовать только между собой. Такая организация контроля доступа позволяет сделать реализации средств защиты и функциональных служб полностью независимыми и устраняет необходимость взаимодействия между пользовательскими процессами и средствами защиты. Данный подход позволяет избежать появления узявимостей, связанных с ошибками в реализации средств защиты.
В качестве базовой модели управления доступом в ОС «Феникс» используется комбинация классической принудительной модели и оригинальной избирательной модели иерархического управления распространением полномочий.
Принудительная и избирательная модели доступа реализуются соответствующими службами, поддерживающими монитор взаимодействий при принятии решения о доступе. Для контроля доступа к объектам любого сервера возможно применение правил как одной, так и другой модели по отдельности или одновременно. В последнем случае доступ разрешается только в том случае, если он не противоречит правилам ни той, ни другой модели.
Дополнительной функцией монитора взаимодействий в системе является направление информации о запросах для протокола аудита. Отбор протоколируемых событий и формирование записей журнала осуществляет специальный сервер аудита. Сервер аутентификации подтверждает подлинность пользовательских идентификаторов и взаимодействует с аппаратными устройствами аутентификации. Набор аутентификационных параметров (ключи, пароли и пр.) определяется требованиями к подсистеме аутентификации и может варьироваться в широких пределах.
Организация взаимодействий по принципу клиент-сервер позволяет контролировать работоспособность компонентов «Феникс» и в случае обнаружения отказа осуществлять их перезапуск. Эта функция реализует службу, отвечающую за контроль целостности.
|
|
|
Рис. 2. Внешний вид приложения «Администратор доступа» |
|
|
|
Рис. 3. Организация контроля доступа |
|
|
|
Рис. 6. Экран программы просмотра протокола аудита |
Управление доступом осуществляется с помощью программного средства «Администратора доступа», функционирующего на платформе Windows и взаимодействующего с соответствующими компонентами ОС «Феникс». Все функции «Администратора доступа» могут быть реализованы и непосредственно с консоли «Феникс», однако, при этом администратору придется использовать командный интерфейс. Графический интерфейс «Администратора доступа» состоит из окна управления пользователями и окна управления объектами (рис. 2).
Окно управления пользователями отображает текущую иерархию пользователей, а окно управления объектами — пространство имен объектов ОС «Феникс». Для каждого объекта указывается его имя, время создания, маска прав доступа, метка безопасности и категория объекта.
«Администратор доступа» реализует просмотр иерархии объектов ОС «Феникс». При этом для каждого пользователя, являющегося подчиненным по отношению к текущему пользователю, может быть открыто отдельное окно, отображающее права этого пользователя на доступ к объектам. Предусмотрена возможность оперативного изменения режима отображения информации в окне управления объектами (скрытие недоступных объектов, сортировка содержимого текущего каталога по именам объектов, дате их создания, убывания/возрастания прав доступа, меток безопасности или категорий).
 |
|
Рис. 4. Установка атрибутов безопасности в ОС «Феникс» |
 |
|
Рис. 5. Параметры учетной записи пользователя |
Под управлением атрибутами объектов понимается возможность изменения уровня безопасности или категории. Для изменения атрибутов безопасности объекта необходимо открыть контекстное меню (рис. 4).
«Администратор доступа» поддерживает выполнение групповых операций над объектами (установка прав или изменение меток доступа для группы выбранных объектов). Выбор объектов осуществляется как стандартным способом (при помощи мыши и клавиатуры в окне управления файлами) так и при помощи фильтров (в качестве критерия выбора можно использовать регулярное выражение). Кроме этого, любая операция установки атрибутов безопасности (в том числе и над группой объектов) может быть выполнена рекурсивно (для объекта-контейнера операция установки атрибутов безопасности выполняется как над ним самим, так и над объектами расположенными в иерархии под ним).
«Администратор доступа» осуществляет управление учетными записями пользователей ОС «Феникс». В главном окне отображается доступный для активного (зарегистрировавшегося) пользователя фрагмент иерархии — сведения о его подчиненных. Для добавления нового пользователя в систему необходимо ввести его учетное имя, пароль, установить метку безопасности и категории (рис. 5). После этого пользователь становиться подчиненным текущего выделенного пользователя.
Протокол аудита состоит из записей, включающих набор полей, среди которых время генерации записи, имя объекта, уровень секретности объекта и др. Протокол имеет табличное представление (рис. 6). Строки таблицы представляют собой записи, выбранные в результате фильтрации, а столбцы — отображаемые поля записей. Пользователю предоставляется возможность включения/отключения отображения полей записей и сортировки таблицы по любому полю.
Максимальное количество атрибутов равно девятнадцати: время события, тип события, идентификатор события, тип сообщения, идентификатор сообщения, номер процесса, идентификатор субъекта, сервер, идентификатор объекта, уровень субъекта, категории субъекта, уровень объекта, категории объекта, права доступа, результат операции, комментарий. Отбор записей может осуществляться по тринадцати критериям: тип события; тип сообщения; идентификатор субъекта; идентификатор объекта; время; результат операции; идентификатор процесса; идентификатор сервера; уровень субъекта; уровень объекта; категории субъекта; категории объекта; права доступа.
Совместимость «Феникс» с ОС Unix на уровне программных интерфейсов достигается при помощи специальной библиотеки для POSIX-приложений. Данная библиотека включает множество основных вызовов стандартных библиотек Unix, реализация которых не вступает в конфликт с основным назначением «Феникс» — обеспечением безопасности.
Обеспечение строгой совместимости означало бы заимствование архитектуры Unix и наследование присущих ей уязвимостей. Для защищенной ОС с гибкой политикой безопасности, какой является «Феникс», достижение полного соответствия программным интерфейсам ОС Unix не представляется возможным. Удовлетворительным уровнем обеспечения совместимости для защищенной ОС следует считать достижение возможности переноса прикладного программного обеспечения, не реализующего функции защиты или администрирования.
Эмуляция системных вызовов Unix на уровне приложений позволяет избавить сервисы от необходимости обеспечивать трансляцию вызовов POSIX в методы УНИДО и исключает влияние инородных программных интерфейсов, унаследованных от незащищенных систем на компоненты OC «Феникс».
Применение специальной защищенной ОС в качестве основного компонента защищенных систем в совокупности с использованием стандартных прикладных программ позволяет достичь весьма высокого уровня безопасности и получить достаточно универсальные решения, которые могут быть использованы для хранения и обработки закрытой информации, имеющей гриф секретности, или критических данных (например, ключевой информации в криптографических системах). Кроме того, возможно использование «Феникс» в качестве базовой платформы для средств защиты (систем управления безопасностью, межсетевых экранов, сетевых фильтров, средств шифрования и т.д.) или как базовой ОС для встроенного программного обеспечения устройств, для которых безопасность имеет существенное значение.
В качестве типовых решений защищенных систем обработки информации, основанных на ОС «Феникс», осуществляется разработка ряда интегрированных защищенных комплексов обработки информации.
Предусматривается проведение сертификации разрабатываемых комплексов в соответствии со стандартами Российской Федерации (получение сертификатов Гостехкомиссии, ФАПСИ, Министерства обороны).
1. Семьянов П.В., Медведовский И.Д., Леонов Д.Г. Атака на Internet // М.: ДМК, 1999
2. Зегжда Д. П. Анализ предпосылок нарушений безопасности в Internet // «Вестник связи», 1999, № 4
3. Зегжда Д. П., Ивашко А. М. Основы безопасности информационных систем // М.: Горячая линия-Телеком, 2000
4. Зегжда Д. П. Общая схема мандатных моделей безопасности и ее применение для доказательства безопасности систем обработки информации // «Проблемы информационной безопасности. Компьютерные системы.», 2000, № 2, СПбГТУ
5. Степанов П.Г. Принципы управления ресурсами в защищенной ОС «Феникс». // «Проблемы информационной безопасности», 1999, № 4, СПбГТУ
Дмитрий Зегжда (dmitry@ssl.stu.neva.ru) — сотрудник Специализированного центра защиты информации, Санкт-Петербургский технический университет, (Санкт-Петербург).
Основу технологии создания защищенных систем составляют следующие принципы.
1. Принцип интегрированности — средства защиты должны быть встроены в систему таким образом, чтобы все без исключения механизмы взаимодействия находились под их контролем. При разработке защищенной ОС следование этому принципу означает осуществление тотального контроля. Самый простой метод тотального контроля состоит в ограничении числа механизмов взаимодействия и интеграции средств защиты прямо в эти механизмы.
2. Принцип инвариантности — средства защиты не должны зависеть от особенностей реализации приложений и не должны учитывать логику их функционирования, напротив они должны быть универсальны для всех типов взаимодействий и отображать их на отношениях между субъектами и объектами. Для ОС инвариантность средств защиты может быть достигнута путем применения строго регламентированной парадигмы функционирования приложений, ограничивающей способы взаимодействий.
3. Принцип унификации — должно существовать однозначное соответствие между контролируемыми взаимодействиями субъектов и объектов и операциями доступа, управление которыми описывается моделями безопасности. Это позволяет придать универсальность средствам защиты и использовать их без изменения как для реализации различных моделей безопасности, так и для контроля доступа к объектам различной природы. Следование этому принципу при разработке ОС приводит к необходимости создания универсального интерфейса доступа, объединяющего все способы взаимодействия между субъектами и объектами, все функции которого однозначным образом отображаются на множество операций, описываемых моделью безопасности.
4. Принцип адекватности — для обеспечения реальной способности противостоять атакам необходимо устранить источники возникновения уязвимостей, на использовании которых основаны все механизмы реализации атак. Как показали исследования [2], основная причина появления уязвимостей состоит в отсутствии последовательного подхода к контролю доступа. Существующие системы содержат привилегированные средства и службы, которые передают пользователям часть своих полномочий в обход средств контроля. Любая программная ошибка в таких средствах ведет к появлению уязвимости. Для операционной системы устранение причин появления уязвимостей означает обязательный контроль доступа на основе универсального интерфейса и единого механизма взаимодействия без каких-либо исключений, и минимизацию объема доверенного кода самих средств защиты с целью уменьшения вероятности появления в них ошибок.
5. Принцип корректности — средства защиты должны реализовывать управление доступом в соответствии с формальными моделями. Наличие непротиворечивой модели безопасности позволяет формально обосновывать безопасность системы, предоставляет объективный критерий корректности ее работы, а также может служить основой для построения исчерпывающих тестов, проверяющих правильность работы средств защиты для всех ситуаций. Для защищенной ОС этот принцип предопределяет управление доступом на основе формальных моделей безопасности.
В основе дискретного доступа лежит возможность конкретно указать тип доступа для любой пары субъект-объект, возможность объединения субъектов в группы для удобства манипулирования их правами, а также ограничение процесса распространения прав. Специально разработанная для ОС «Феникс» модель использует строго иерархическую структуру пользователей, заданную отношением начальник-подчиненный, в которой права доступа строго возрастают от подчиненного к начальнику. Каждый начальник имеет полное управление объектами подчиненных ему пользователей и отвечает за распространение на них прав доступа. На вершине иерархии находится супервизор, обладающий максимальными полномочиями, однако, это не означает, что в системе может существовать такой пользователь.
Для каждой пары субъектов и объектов доступ регулируется с помощью стандартного набора прав (чтение, запись, добавление, выполнение) и прав управления доступом. Управление распространением полномочий осуществляется с помощью трех прав: права изменять права доступа для самого себя (m), права назначать права доступа для других (с) и права передавать другим управление доступом (cp). Все права могут встречаться в любых комбинациях кроме пары c и cp — для наличия cp необходимо наличие c. Изменение прав доступа m дает субъекту право на изменение своих прав доступа к объекту, но не дает права устанавливать права c и cp. Управление доступом c — дает право субъекту назначать права доступа к объекту для своих подчиненных, но не более чем имеет он сам (изменять свои права этот атрибут не позволяет). Право на передачу управления доступом cp позволяет субъекту назначать своим подчиненным право с.
Таким образом управление доступом осуществляется с помощью трех правил:
1. Определение прав доступа для пары субъект-объект. В таблице прав явно указаны права доступа каждого субъекта к каждому объекту.
2. Генерация прав доступа для объекта созданного субъектом. Для каждого объекта, созданного субъектом назначаются следующие права доступа:
3. Установка субъектом прав доступа некоторого субъекта объекту. Субъект S1 может устанавливать набор прав P субъекту S2 для объекта O в соответствии со следующими ограничениями:
Права в рамках своих означает следующее:
Все функции политики безопасности по отношению к каталогам осуществляются согласно тем же правилам, что и для данных.
При использовании любой дискреционной модели существует возможность утечки информации с помощью запуска «троянского коня». Адекватную защиту от этой атаки обеспечивает только принудительная система разграничения доступа, однако, в предложенной модели иерархического управления распространением полномочий предусмотрены меры по ограничению возможности применения подобной атаки. Во-первых, благодаря иерархической организации субъектов утечка информации может происходить только в направлении подчиненных субъекта, запустившего опасную программу (т.е. только вниз по дереву иерархии субъектов, но не по горизонтали). Во-вторых, для любого начальника в отношении файлов подчиненных по умолчанию установлено только право на чтение (но не на запись и выполнение), поэтому, пока менеджер самовольно не изменит эти права, любая попытка запуска «троянского коня» будет вызывать противодействие со стороны системы разграничения доступа.
Когда тот или иной физик использует понятие "физический вакуум", он либо не понимает абсурдности этого термина, либо лукавит, являясь скрытым или явным приверженцем релятивистской идеологии.
Понять абсурдность этого понятия легче всего обратившись к истокам его возникновения. Рождено оно было Полем Дираком в 1930-х, когда стало ясно, что отрицание эфира в чистом виде, как это делал великий математик, но посредственный физик Анри Пуанкаре, уже нельзя. Слишком много фактов противоречит этому.
Для защиты релятивизма Поль Дирак ввел афизическое и алогичное понятие отрицательной энергии, а затем и существование "моря" двух компенсирующих друг друга энергий в вакууме - положительной и отрицательной, а также "моря" компенсирующих друг друга частиц - виртуальных (то есть кажущихся) электронов и позитронов в вакууме.
Однако такая постановка является внутренне противоречивой (виртуальные частицы ненаблюдаемы и их по произволу можно считать в одном случае отсутствующими, а в другом - присутствующими) и противоречащей релятивизму (то есть отрицанию эфира, так как при наличии таких частиц в вакууме релятивизм уже просто невозможен). Подробнее читайте в FAQ по эфирной физике.
|
|
 |
