6.18. Safe Haskell

6.18.1.1. Строгая безопасность типов (хороший стиль)

Haskell предлагает мощную систему типов и разделение чистых и эффектных функций с помощью монады IO. Однако в системе типов есть несколько лазеек, самая очевидная из которых — функция unsafePerformIO :: IO a -> a. Диалект безопасного языка Safe Haskell запрещает использование подобных функций. Это полезное ограничение, поскольку оно упрощает анализ кода Haskell и рассуждения о нем. Оно также закрепляет существующую в сообществе Haskell практику избегать небезопасных функций, если только в них нет крайней необходимости. Поэтому использование безопасного языка (с помощью флага -XSafe) можно считать способом обеспечения хорошего стиля, аналогичным назначению -Wall.

6.18.1.2. Создание защищенных систем (ограниченные монады IO)

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

В качестве примера определим интерфейс системы плагинов, авторы которых — недоверенные, возможно злоумышленные сторонние лица. Для этого мы ограничим интерфейс плагина чистыми функциями или ограниченной монадой IO, которую мы определили. Ограниченная монада IO позволит выполнять только безопасное подмножество действий IO. Мы определим интерфейс плагина так, чтобы он требовал от модуля плагина Danger экспортировать одно вычисление Danger.runMe типа RIO (), где RIO — монада, определенная следующим образом:

-- While we use `Safe', the `Trustworthy' pragma would also be
-- fine. We simply want to ensure that:
-- 1) The module exports an interface that untrusted code can't
--    abuse.
-- 2) Untrusted code can import this module.
--
{-# LANGUAGE Safe #-}

module RIO (RIO(), runRIO, rioReadFile, rioWriteFile) where

-- Notice that symbol UnsafeRIO is not exported from this module!
newtype RIO a = UnsafeRIO { runRIO :: IO a }

instance Functor RIO where
    fmap f (UnsafeRIO m) = UnsafeRIO (fmap f m)

instance Applicative RIO where
    pure = UnsafeRIO . pure
    (UnsafeRIO f) <*> (UnsafeRIO m) = UnsafeRIO (f <*> m)

instance Monad RIO where
    (UnsafeRIO m) >>= k = UnsafeRIO $ m >>= runRIO . k

-- Returns True iff access is allowed to file name
pathOK :: FilePath -> IO Bool
pathOK file = {- Implement some policy based on file name -}

rioReadFile :: FilePath -> RIO String
rioReadFile file = UnsafeRIO $ do
    ok <- pathOK file
    if ok then readFile file else return ""

rioWriteFile :: FilePath -> String -> RIO ()
rioWriteFile file contents = UnsafeRIO $ do
    ok <- pathOK file
    if ok then writeFile file contents else return ()

Затем мы скомпилируем плагин Danger с помощью нового флага Safe Haskell -XSafe:

{-# LANGUAGE Safe #-}
module Danger ( runMe ) where

runMe :: RIO ()
runMe = ...

Прежде чем перейти к подробностям Safe Haskell, перечислим некоторые причины, по которым этот механизм безопасности не сработал бы без Safe Haskell:

• В этой конструкции предпринимается попытка ограничить операции, которые может выполнять Danger, с помощью типов, в частности оболочки типа RIO вокруг IO. Однако автор Danger может обойти это ограничение, просто написав произвольные действия IO и используя unsafePerformIO :: IO a -> a для их выполнения в виде чистых функций.
• Конструкция также предполагает, что Danger не сможет получить доступ к конструктору UnsafeRIO. К сожалению, Template Haskell можно использовать для обхода границ модулей и получения доступа к этому конструктору.
• Невозможно ограничить список модулей, которые может импортировать Danger. Это предоставляет автору Danger очень широкую поверхность для атаки, включающую практически любой пакет, установленный в системе. Если в каком-либо из этих пакетов есть уязвимость, модуль Danger сможет ее использовать.

Safe Haskell предотвращает все эти атаки. Для этого модуль RIO компилируется с флагом Safe или Trustworthy, а Danger компилируется с флагом Safe. Ниже мы объясним каждый из них.

Использование Safe для компиляции Danger ограничивает доступные возможности Haskell безопасным подмножеством (safe subset). Это включает запрет на unsafePerformIO, Template Haskell, чистые функции FFI и RULES, а также ограничение работы перекрывающихся экземпляров. Флаг Safe также ограничивает список модулей, которые может импортировать Danger, только теми, которые считаются доверенными. Доверенными являются модули, скомпилированные с помощью Safe, для которых GHC механически гарантирует безопасность кода, либо модули, скомпилированные с помощью Trustworthy, автор которых заявляет, что модуль безопасен.

Именно поэтому модуль RIO компилируется с помощью Safe или Trustworthy, чтобы модуль Danger мог его импортировать. Флаг Trustworthy, в отличие от Safe, не накладывает на модуль никаких ограничений (кроме ограничения на перекрывающиеся экземпляры, которые должны быть безопасными перекрывающимися экземплярами). Вместо этого автор модуля заявляет, что, хотя внутри код может использовать небезопасные возможности, он предоставляет API, которым можно безопасно пользоваться.

Однако свободное использование Trustworthy представляет проблему: произвольный модуль может использовать его, чтобы объявить себя доверенным, хотя Trustworthy не дает никаких гарантий относительно модуля, в отличие от Safe. Для контроля использования заслуживающих доверия модулей рекомендуется использовать флаг -fpackage-trust. Этот флаг добавляет дополнительное условие при проверке доверия к заслуживающим доверия модулям. Чтобы такие модули считались доверенными и могли использоваться в коде, скомпилированном с помощью Safe, клиент C, компилирующий код, должен сообщить GHC, что доверяет пакету, в котором находится заслуживающий доверия модуль. По сути, это способ для C заявить: хотя этот пакет содержит заслуживающие доверия модули, которые могут использоваться недоверенными модулями, скомпилированными с помощью Safe, я доверяю автору или авторам этого пакета и верю, что модули предоставляют только безопасный API. Уровень доверия к пакету можно изменить в любой момент: поэтому, если в пакете обнаружена уязвимость, C может объявить пакет недоверенным, и любая последующая компиляция с использованием этого пакета завершится ошибкой. Более подробное описание этого механизма см. в разделе Доверие и режимы Safe Haskell.

В этом примере Danger может импортировать модуль RIO, поскольку RIO скомпилирован с помощью Safe. Таким образом, Danger может использовать функции rioReadFile и rioWriteFile для доступа к разрешенным именам файлов. Затем основное приложение импортирует и RIO, и Danger. Чтобы запустить плагин, оно вызывает RIO.runRIO Danger.runMe в монаде IO. Приложение может быть уверено, что единственные возникающие IO будут относиться к файлам, пути к которым одобрены проверкой pathOK.

Проверки Safe Haskell можно отключить для модуля, передав флаг -fno-safe-haskell. Это особенно полезно при компиляции с плагинами исходного кода: запуск плагина помечает модуль как небезопасный и может привести к тому, что последующие модули не пройдут проверки безопасности.

6.18.2.1. Безопасные перекрывающиеся экземпляры

Из-за гарантии семантической согласованности Safe Haskell необходимо ограничить работу перекрывающихся экземпляров. Мы не ограничиваем возможность их определения, поскольку это глобальное свойство, которое нельзя определить, анализируя один модуль. Вместо этого при вызове модулем функции, принадлежащей классу типов, мы проверяем, считается ли выполненное разрешение экземпляра «безопасным». Эта проверка применяется к модулям, скомпилированным как с -XSafe, так и с -XTrustworthy.

Рассмотрим следующие модули:

{-# LANGUAGE Safe #-}
module Class (TC(..)) where
  class TC a where { op :: a -> String }

{-# LANGUAGE Safe #-}
module Dangerous (TC(..)) where
  import Class

  instance
    {-# OVERLAPS #-}
    TC [Int] where { op _ = "[Int]" }

{-# LANGUAGE Safe #-}
module TCB_Runner where
  import Class
  import Dangerous

  instance
    TC [a] where { op _ = "[a]" }

  f :: String
  f = op ([1,2,3,4] :: [Int])

И модуль Class, и модуль Dangerous скомпилируются с помощью Safe без проблем. Однако в модуле TCB_Runner необходимо проверить, безопасен ли вызов op в функции f.

Что значит «безопасный»? Импорт модуля, скомпилированного с помощью Safe, не должен менять смысл кода, который успешно компилируется без импорта этого модуля. Это свойство Safe Haskell называется семантической согласованностью.

В нашем случае модуль TCB_Runner успешно компилируется без импорта модуля Dangerous. Поэтому при выборе экземпляра для вызова op небезопасной будет ситуация, в которой экземпляр TC [Int] из модуля Dangerous окажется наиболее специализированным. Это не позволяет написанному сторонними разработчиками, которым мы не доверяем, коду (скомпилированному с помощью -XSafe в Safe Haskell) менять поведение уже существующего кода.

В частности, для определения того, является ли вызов метода класса типов небезопасным при наличии перекрывающихся экземпляров, применяется следующее правило:

• Наиболее специализированный экземпляр Ix определен в скомпилированном модуле -XSafe.
• Ix — осиротевший экземпляр или экземпляр многопараметрического класса типов.

• По крайней мере один перекрываемый экземпляр Iy одновременно удовлетворяет следующим условиям:

  • Он находится в модуле, отличном от Ix
  • Iy не помечен как OVERLAPPABLE

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

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

6.18.4.1. Проверка доверия (-fpackage-trust отключён)

Модуль M из пакета P доверен клиентом C тогда и только тогда, когда:

• Выполняются оба условия:

  • Модуль скомпилирован с Safe
  • Все прямые импорты M доверены клиентом C

• или выполняются все условия:

  • Модуль скомпилирован с Trustworthy
  • Все прямые безопасные импорты M доверены клиентом C

У приведённого выше определения доверия есть проблема. Любой модуль можно скомпилировать с Trustworthy, и он будет считаться доверенным. Чтобы контролировать это, используется дополнительное определение доверия к пакету (включаемое флагом -fpackage-trust). Доверие к пакету требует, чтобы клиент C явно указал, в каких пакетах могут содержаться модули, заслуживающие доверия. Пакеты, заслуживающие доверия, считаются доверенными, только если они находятся в пакете, которому доверяет C.

6.18.4.2. Проверка доверия (-fpackage-trust включён)

Если флаг -fpackage-trust включён, то доверие к модулю зависит от того, доверяют ли определённым пакетам. Доверие к пакетам определяется клиентом C, вызывающим GHC (то есть вами).

В частности, пакет P заслуживает доверия, если выполняется одно из следующих условий:

• В базе данных пакетов клиента C указано, что P является доверенным (и аргументы командной строки не переопределяют это)
• Флаги командной строки клиента C указывают доверять P независимо от записей в базе данных пакетов.

В обоих случаях только клиент C определяет, каким пакетам доверять. Клиент решает, каким пакетам он доверяет.

При использовании флага -fpackage-trust модуль M из пакета P доверен клиентом C тогда и только тогда, когда:

• Выполняются оба условия:

  • Модуль скомпилирован с Safe
  • Все прямые импорты M доверены клиентом C

• или выполняются все условия:

  • Модуль скомпилирован с Trustworthy
  • Все прямые безопасные импорты M доверены клиентом C
  • Пакет P доверен клиентом C

В первом определении доверия гарантию предоставляет GHC за счёт ограничений, накладываемых безопасным языком. Во втором определении доверия гарантию изначально предоставляет автор модуля. Затем клиент C подтверждает, что доверяет автору модуля, указывая, что доверяет пакету, в котором находится модуль. Эта цепочка доверия необходима, поскольку GHC не предоставляет никаких гарантий для модулей, скомпилированных с Trustworthy.

Существуют два режима проверки доверия, поскольку дополнительное требование, включаемое флагом -fpackage-trust, делает Safe Haskell навязчивым. Пакеты, использующие Safe Haskell при включённом флаге, могут компилироваться или не компилироваться в зависимости от состояния доверенных пакетов на компьютере пользователя. Это не только ненадёжно, но и приводит к сбоям компиляции у всех, даже если они не собираются использовать какие-либо гарантии Safe Haskell. Отключение -fpackage-trust по умолчанию и его преобразование в флаг делают Safe Haskell расширением, включаемым по желанию, а не постоянно активной возможностью.

6.18.4.3. Пример

Package Wuggle:
    {-# LANGUAGE Safe #-}
    module Buggle where
        import Prelude
        f x = ...blah...

Package P:
    {-# LANGUAGE Trustworthy #-}
    module M where
        import System.IO.Unsafe
        import safe Buggle

Предположим, клиент C решил доверять пакету P и пакету base. Доверяет ли тогда C модулю M? Модуль M помечен как Trustworthy, поэтому мы не ограничиваем язык. Однако нам всё ещё нужно проверить импорты M:

• Во-первых, M импортирует System.IO.Unsafe. Это небезопасный модуль, однако M был скомпилирован с Trustworthy, поэтому автор P берёт на себя ответственность за этот импорт. C доверяет автору P, поэтому этот импорт допустим.
• Во-вторых, M безопасно импортирует Buggle. В случае этого импорта автор P не берёт на себя ответственность за безопасность, а просит GHC проверить, доверяет ли C модулю Buggle. Доверяет ли?
• Buggle скомпилирован с -XSafe, поэтому корректность кода проверяется машиной, но при этом предполагается, что всем импортам Buggle доверяет C. Нужно рекурсивно проверить все импорты!
• Buggle импортирует только Prelude, скомпилированный с Trustworthy. Prelude находится в пакете base, которому доверяет C, и (будем считать) всем импортам Prelude также доверяют. Следовательно, C доверяет Prelude, а значит, C также доверяет Buggle. (Хотя Prelude обычно импортируется неявно, на него распространяются те же правила, что описаны здесь.)

Обратите внимание, что C не нужно было доверять пакету Wuggle: достаточно машинной проверки. C нужно доверять только пакетам, содержащим модули Trustworthy.

6.18.4.4. Требования к модулям Trustworthy

Авторы модулей, использующие языковое расширение Trustworthy для модуля M, должны удостовериться, что публичный API M (символы, предоставляемые списком экспорта) нельзя использовать небезопасным образом. Это означает, что экспортируемые символы должны обеспечивать типобезопасность и ссылочную прозрачность.

6.18.4.5. Доверие к пакетам

Safe Haskell добавляет пакетам новое булево свойство — доверие. Для указания этого свойства пакетов доступны несколько новых параметров командной строки GHC:

-trust ⟨pkg⟩

Предоставляет пакет ⟨pkg⟩, если он был скрыт, и считает его доверенным независимо от базы данных пакетов.

-distrust ⟨pkg⟩

Предоставляет пакет ⟨pkg⟩, если он был скрыт, и считает его недоверенным независимо от базы данных пакетов.

-distrust-all-packages

Считает все пакеты недоверенными, если последующие параметры командной строки явно не пометят их как доверенные.

Сведения об установке свойства доверия пакета в базе данных пакетов см. в разделе Пакеты.