Safe Haskellは、コンパイルされたコードの性質に関して、Haskellを使ってセキュアなシステムを構築するのに十分なだけの保証を与えるように設計されている。情報フロー制御、capability-basedセキュリティ、暗号化されたデータを扱うためのDSL、といったシステムをHaskellで構築するための作業が大量に為されてきた。これらのシステムは全て、unsafePerformIOのような関数が許される一般の場合には成り立たないようなHaskell言語の性質に依拠している。

例として、プラグイン作者が信用されず、悪意のある第三者かもしれないようなプラグインシステムのためのインタフェースを定義してみよう。このために、プラグインのインタフェースを純粋な関数にするか、IO動作の安全なサブセットしか実行することを許されないような制限されたIOモナドにする。ここではプラグインのインタフェースを以下のようにする。すなわち、プラグインモジュールDangerは、型RIO ()を持つ単一の計算Danger.runMeを定義することを要求される。ただしRIOは以下のように定義された新しいモナドである。

        -- 以下のSafe Haskellのプラグマはどちらでも良い
        {-# LANGUAGE Trustworthy #-}
        {-# LANGUAGE Safe #-}

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

        -- UnsafeRIOシンボルがこのモジュールからエクスポートされていないのに注意！
        newtype RIO a = UnsafeRIO { runRIO :: IO a }

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

        -- ファイル名にアクセスが許可されている場合、かつその場合に限りTrue
        pathOK :: FilePath -> IO Bool
        pathOK file = {- ファイル名についての何らかのポリシーの実装 -}

        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 ()
      

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

        runMe :: RIO ()
        runMe = ...
      

これらの攻撃を止めるためにSafe Haskellを使うことができる。これには、RIOモジュールを-XTrustworthyフラグ付きでコンパイルし、Dangerモジュールを-XSafeフラグ付きでコンパイルする。

-XSafeフラグを使うことで、利用可能なHaskellの機能を安全なサブセットに限定してDangerモジュールをコンパイルすることができる。これには、unsafePerfromIO、Template Haskell、純粋なFFI関数、一般化newtype deriving、RULESを禁止し、重複インスタンスの操作に制限を加えることを含む。さらに、-XSafeは、Dangerがインポートできるモジュールを信頼されているとみなされるもののみに制限する。信頼されるモジュールは、-XSafe付きでコンパイルされたもの(この場合、コードが安全であることをGHCが機械的に保証する)または、-XTrustworthy付きでコンパイルされたもの(この場合、モジュール作者がこのモジュールが安全だと主張する)である。

これが、RIOモジュールがDangerモジュールからインポートできるように-XTrustworthy付きでコンパイルされている理由である。-XTrustworthyは、-XSafeと異なり、モジュールについていかなる制限も課さない。代わりに、コードが内部的にunsafeな機能を使っていても、安全に使えるAPIしか露出していないということをモジュール作者が主張する。ここで、問題が一つある。あらゆるモジュールのあらゆる作者が-XTrustworthyを使えるのである。このため、Trustworthyとされたモジュールが信頼され、-XSafeでコンパイルされるコードから使うことを許されるためには、コードをコンパイルしているクライアントCが、このTrustworthyとされたモジュールが所属するパッケージを信頼する旨をGHCに伝えなければならない。これは実質的に、「このパッケージは-XSafeでコンパイルされる信頼されないモジュールによって使えるTrustworthyモジュールを含んでいるが、私はこのパッケージの作者を信頼し、このモジュールが安全なAPIしか露出しないことを信頼する」と言う手段をCに与える。パッケージへの信頼はいつでも変えられるので、もしパッケージに脆弱性が見付かったら、Cはそのパッケージが信頼されないと宣言し、そのパッケージに対する将来のいかなるコンパイルも失敗するようにできる。この機構についてのより詳細な概観は7.20.4. 信頼を見よ。

以上により、RIOはTrustworthyと標示されているのでDangerはRIOをインポートできる。よって、DangerはrioReadFileとrioWriteFileの各関数を使って許可されたファイル名にアクセスできる。次に主アプリケーションがRIOとDangerの両方をインポートし、RIO.runRIO Danger.runMeをIOモナド中で呼ぶことでプラグインを走らせる。pathOKの検査によって認められたパスを持つファイルにしかIOできないと分かっているので、このアプリケーションは安全である。

        パッケージWuggle:
           {-# LANGUAGE Safe #-}
           module Buggle where
             import Prelude
             f x = ...blah...

        パッケージP:
           {-# LANGUAGE Trustworthy #-}
           module M where
             import System.IO.Unsafe
             import safe Buggle
      

クライアントCがパッケージPを信頼することを決めたとしよう。ではCはモジュールMを信用するか？これを決めるために、GHCはMのインポートを検査しなければいけない。MはSystem.IO.Unsafeをインポートしている。Mは-XTrustworthy付きでコンパイルされているから、このインポートについてはMの作者が責任を負う。CはPの作者を信頼しているので、CはMがunsafeなインポートを安全かつMが露出するAPIに整合的な形でしか使わないということを信頼している。Mには、BuggleへのSafeインポートもある。safeインポートなのでPの作者はこれの安全性について責任を負わないため、BuggleがCに信頼されているかをGHCが検査しないといけない。どうか？うーん、これは-XSafe付きでコンパイルされているので、Buggle自体のコードは問題ないことが機械的に検査されている。ただしこれもBuggleのインポートが全てCに信頼されていることが条件である。Preludeはbase由来であり、Cはこれを信頼しており、-XTrustworthy付きでコンパイルされている。(Preludeは典型的には暗黙にインポートされるが、その場合でもここで述べた規則に沿う)。よってBuggleは信頼されているとみなされる。

CはパッケージWuggleを信頼する必要がなかったことに注意。機械による検査だけで十分である。Cは、-XTrustworthyなモジュールを含むパッケージだけを信頼すれば良い。

        import safe Untrusted.Module