Grsecurity

Grsecurity のホームページより:

既知の脆弱性のパッチや、シグネチャベースの検出、その他の反応的な方法を使ってセキュリティを高めているようなふりをする他の高価なセキュリティ"ソリューション"とは異なり、grsecurity は本当の率先的なセキュリティを提供します。アプリケーションとオペレーティングの両方を強固にする唯一の方法として、grsecurity は公に公開するサーバーや共用のホスティング環境で必須と言えるでしょう。

grsecurity プロジェクトは Linux カーネルのセキュリティを高めるためのパッチを提供しています。一般的な攻撃ベクトルに対してカーネルを強固にし、絶え間なく生まれる脆弱性によってカーネルが危ない状態になるのを防ぎます。楽チンな自動学習モードがあるパワフルな強制アクセス制御 (Mandatory Access Control) システムが含まれています。また、PaX パッチも含まれており、強力なメモリー保護や ASLR によってエクスプロイトに対してユーザースペースのアプリケーションを強固にします。

インストール

ノート: linux-grsec と他のパッケージの非互換性はそのパッケージのバグとして報告しないでください。linux-grsec パッケージのバグとして報告されるべきであり、それで修正されるか、またはこのページに互換性問題としてまとめられます。

公式リポジトリの linux-grsec パッケージは grsecurity によって強化されたカーネルを提供します。基本的には、標準カーネルと完全に互換があり問題は発生しません。デフォルトで、ユーザーが使える機能はほとんど無効になっていますが、それでも攻撃に対するカーネルの著しい強化がなされます。

任意で paxd パッケージをインストールすることで PaX による脆弱性攻撃の弱体化が有効にされ、ユーザースペースのプロセスが保護されます。/etc/paxd.conf 設定ファイルで指定したリポジトリのパッケージや一般的なサードパーティ製のソフトウェアの必要な例外を設定するデーモンが入っています。これらの例外は Pacman の処理や設定ファイルを変更した後に再度適用されます。再起動後に自動で起動します (無効にするようマスクすることも可能です)。

さらに checksec, pax-utils, paxtest パッケージには PaX を使用したりエクスプロイト攻撃弱体化技術が有効かどうか検証するのに便利なツールが含まれています。

任意の gradm パッケージには RBAC ポリシーを管理するためのユーザースペースツールが入っています。RBAC はデフォルトで無効になっており、重要な設定をしないかぎりサンプルのポリシーは使い物になりません (学習モードを多用するなど)。

カスタムカーネル

公式パッケージをベースにしてカスタムカーネルを ABS でコンパイルすることは考慮に値します。パフォーマンスとセキュリティのバランスを取るための様々な妥協があり、公式設定は頑丈ではありますが、あらゆるユースケースにうってつけとは言えません。/proc と /sys の制限はあまりに多くのソフトウェアを破壊してしまうため汎用なパッケージとしては受け入れられませんが、有効にすることで情報の漏洩の危険性を減らすのに役立つ可能性があります。使われているオプションの理論的な根拠については DeveloperWiki:Security#grsecurity を見て下さい。

RANDSTRUCT プラグインやシンボルのアドレスの秘匿などの機能はカスタムカーネルでのみ意味を成し得ます、攻撃者はビルド済みのカーネルならば解析することができるからです。現在無効になっている他の機能については CONFIG_XEN (UDEREF, KERNEXEC) との非互換性や性能のオーバーヘッドが大きい (performance オプションなしの RANDSTRUCT, x86_64 の UDEREF, x86_64 の KERNEXEC, MEMORY_SANITIZE) のが原因です。

ユーザーの分離にも基づく /proc の強化は /proc に hidepid マウントオプションを使うことで可能で、あまり大きなロスはありません。AUR のオリジナルの linux-grsec では他のグループベースのホワイトリストモデルを使って厳格な /proc 制限を有効にしていました。これは arsch リポジトリ や手動でインストールできます。

互換性

以下のパッケージは既知の非互換性があります:

• pkgstats - ロードされたモジュールを非 root で表示しようとして致命的なエラーとして扱います

PaX

PaX プロジェクトは grsecurity に使われている多数の脆弱性攻撃弱体化を提供しています。詳しくは PaX のドキュメントを見て下さい。

Trusted path execution

Trusted path execution (TPE) はファイルの実行を規制する選択的な機能です。kernel.grsecurity.tpe sysctl を 1 に設定することで有効にできます。TPE は root でないユーザーが書き込み可能なファイルを実行してしまうことを防止します。ファイルの実行のルールを厳しくすることで、(ウェブサーバーのアップロード + CGI エクスプロイトなど) 脆弱性攻撃や永続的なバックドアをある程度予防できます。

tpe グループをホワイトリストやブラックリストとして使う

デフォルトで、kernel.grsecurity.tpe_invert は 1 に設定されており、ホワイトリストベースモデルで TPE を使うようになっています。規制は tpe グループのメンバーでない全てのユーザーに適用されます。kernel.grsecurity.tpe_invert が 0 に設定されている場合、反対に tpe グループは制限を受けるユーザーのブラックリストとして機能し、グループに入っていないユーザーは影響を受けません。

ホワイトリストモデルが推奨され、通常はシステム管理を行わないユーザーをホワイトリストに追加するだけで十分です。root 以外で実行されるサービスの隔離を少しだけ改善させます。

互換性

コンテナや普通の chroot はそれぞれローカルの /etc/group を保持するため、TPE の使い勝手の良さが台無しになる可能性があります。コンテナ内の同じ id のグループもホワイトリストとして機能しますが、コンテナがユーザー名前空間を使うと破壊されます (Arch のカーネルではサポートされていません)。

root でない全てのユーザーに一部制限をかける

kernel.grsecurity.tpe_restrict_all sysctl スイッチを 1 に設定すると root でないユーザーが、他のユーザーや root によって書き込み可能なファイルを実行するのを止めます。この機能は互換性の問題がないかぎり基本的に有効にすることができますが、現在のところデフォルトで無効になっています。

RBAC

ロールベースアクセス制御 (Role Based Access Control)

ファイル (もしくは総じて情報) への不正アクセスを防ぐのに使われるアクセス制御メカニズムには基本の2つのタイプがあります: DAC (Discretionary Access Control, 任意アクセス制御) と MAC (Mandatory Access Control, 強制アクセス制御) です。デフォルトで、Linux は DAC メカニズムを使っています: ファイルの作成者がファイルにアクセスできるユーザーを定義します。逆に MAC システムでは全てのユーザーが管理者の設定したルールに従います。

grsecurity がサポートしている MAC の実装はロールベースアクセス制御 (Role Based Access Control) と呼ばれます。RBAC はそれぞれのユーザーにロール（役割）を割り当てます。各ロールには特定のオブジェクトで実行できる操作が何かを定義します。ロールと操作の集合を上手く記述すれば、ユーザーは管理者がしても良いと命じた作業だけしか行えないように制限されます。デフォルトの "deny-all" では管理者が考えていない行動をユーザーが行えないことが保証されます。

gradm を使う

gradm はシステムのポリシーを管理・整備するためのツールです。これを使って、RBAC システムを有効化・無効化したり、RBAC ルールをリロード、ロールを変更、管理モードのパスワードの設定などができます。

gradm をインストールするとデフォルトのポリシーが /etc/grsec/policy にインストールされます。

デフォルトでは、RBAC ポリシーは有効になっていません。システムに RBAC ポリシーをいつ発動させるか決めるのはシステム管理者の仕事です。RBAC システムを有効にする前に管理者パスワードを設定してください。

# gradm -P admin
Setting up grsecurity RBAC password
Password: (Enter a well-chosen password)
Re-enter Password: (Enter the same password for confirmation)
Password written in /etc/grsec/pw
# gradm -E

RBAC システムを無効化するには、gradm -D を実行してください。無効化の権限がない場合、まず admin ロールに切り替える必要があります:

# gradm -a admin
Password: (Enter your admin role password)
# gradm -D

admin ロールから外れたい場合、次を実行してください:

# gradm -u admin

ポリシーを生成する

RBAC システムには"学習モード"という名前の素晴らしい機能があります。学習モードはあなたのシステムにあわせて予測による最低限の権限ポリシーを生成することができます。これによって時間とお金を節約して、迅速に多数のセキュアなサーバーを配置することが可能になります。

学習モードを使うには、gradm を使って有効にしてください:

# gradm -F -L /etc/grsec/learning.log

次にシステムを使用します、通常通りに作業を行なって下さい。locate や rsync などのファイル i/o の負担が重い操作は避けるようにしてください、処理時間が大幅にスローダウンしてしまいます。

適切なポリシーを作るのに十分だと思えるほどシステムを使用したら、gradm に処理させて /etc/grsec/learning.roles にロールを作成してください:

# gradm -D
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles

/etc/grsec/learning.roles を検査して問題なかったら /etc/grsec/policy (モード 0600) として保存して完了です。

# mv /etc/grsec/learning.roles /etc/grsec/policy
# chmod 0600 /etc/grsec/policy

これで新規学習したポリシーを使って RBAC システムを有効にすることが可能になりました。

# gradm -E

ポリシーを調整する

grsecurity 2.x の興味深い機能に設定ファイルの Set Operation Support があります。現在、(この場合オブジェクトの) 和集合・積集合・差集合をサポートしています。

define objset1 {
/root/blah rw
/root/blah2 r
/root/blah3 x
}

define somename2 {
/root/test1 rw
/root/blah2 rw
/root/test3 h
}

以下は使用のサンプルで、作られたオブジェクトはサブジェクトに追加されます:

subject /somebinary o
$objset1 & $somename2

上の場合、次のように展開されます:

subject /somebinary o
/root/blah2 r

This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.

subject /somebinary o
$objset1 | $somename2

この例は以下のように展開されます:

subject /somebinary o
/root/blah rw
/root/blah2 rw
/root/blah3 x
/root/test1 rw
/root/test3 h

This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.

subject /somebinary o
$objset1 - $somename2

この例は以下のように展開されます:

subject /somebinary o
/root/blah rw
/root/blah2 h
/root/blah3 x

This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.

In some obscure pseudo-language you could see this as:

if ( ($objset1 contained /tmp/blah rw) and
     ($objset2 contained /tmp/blah r) )
then
  $objset1 - $objset2 would contain /tmp/blah w

if ( ($objset1 contained /tmp/blah rw) and
     ($objset2 contained / rwx) )
then 
  $objset1 - $objset2 would contain /tmp/blah h

As for order of precedence (from highest to lowest): "-, & |".

If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:

(($set1 - $set2) | $set3) & $set4

/etc/grsec/policy を直接調整する

Sometimes, full learning mode doesnt work for a particular program and direct revisions to the policy file will need to be made. One might simply want to tweak the policy file to add or remove access to directories without requiring one to reinitiate learning mode or recreating a policy file. The file itself is composed of Roles and Subjects. A Role determines what user the ruleset applies to, while the Subject could be seen as what process/program the ruleset applies to.

Consider a situation where the role is "username", while the subject is /usr/lib/firefox/firefox. Within the curly braces of this role/subject rule, directories will be listed, along with flags that dictate what capacities (read, write, execute, etc) you wish to give that subject (firefox for example) under that role (username, when firefox is ran under the user "username" for example). Here is a list of flags and what they do:

  a 	This object can be opened for appending.
  c 	Allow creation of the file/directory.
  d 	Allow deletion of the file/directory.
  f 	Needed to mark the pipe used for communication with init to transfer the privilege of the 		persistent role; only valid within a persistent role. Transfer only occurs when the file is opened for writing.
  h 	This object is hidden.
  i 	This mode only applies to binaries. When the object is executed, it inherits the ACL of the     subject in which it was contained.
  l 	Lowercase L. Allow a hardlink at this path. Hardlinking requires a minimum of c and l modes, and the target link cannot have any greater permission than the source file.
  m 	Allow creation of setuid/setgid files/directories and modification of files/directories to be setuid/setgid.
  p 	Reject all ptraces to this object.
  r 	This object can be opened for reading.
  t 	This object can be ptraced, but cannot modify the running task. This is referred to as a 'read-only ptrace'.
  w 	This object can be opened for writing or appending.
  x 	This object can be executed (or mmap'd with PROT_EXEC into a task).

So for example, if you want firefox to have read access to the home folder of the user username, be able to do everything (read, write, create and destroy files, execute) in /home/username/Downloads, but not be able to see /home/username/secretstuff or anything in /, your ruleset might look like this:

  # Role: username
  subject /usr/lib/firefox/firefox o {
      /                                               h
      /home/username                       r
      /home/username/Downloads     rwxcd
      /home/username/secretstuff      h
  }

Of course, a Firefox ruleset will need more than just the above (like access to directories it needs to run in /usr for example); compare the above with what is generated by full-learning-mode and you quickly see the pattern. The idea is that you want to limit each process as much as possible to limit the changes it can make to the filesystem in the event it is compromised. Much more info is available on the GRsecurity RBAC wiki page.

Wine を使う; /etc/grsec/policy に必要な変更

wine を使用する場合、NTFS パーティション上にある wine アプリの実行可能ファイルを、RBAC を有効にしながら動作させるには、サブジェクトを使ってロール (user) の /usr/bin/wine-preloader の Subject モードに "O" を追加する必要があります。これが .wine にある実行可能ファイルに適用されるのかどうかは不明です。システムを完全学習モードにして wine を実行して、セッションから /etc/grsec/policy を生成しても RBAC は wine プログラムが動作するのを止めます:

grsec: (username:U:/usr/bin/wine-preloader) denied load of writable library /mnt/winblows/Program Files (x86)/Diablo II/Game.exe by /usr/bin/wine-preloader[Game.exe:7518] uid...

Subject モードの最後に "O" を追加することでこの問題を修正できます。ルールセットの例 (subject /usr/bin/wine-preloader の後ろにある大文字の O に注目してください):

# Role: username
subject /usr/bin/wine-preloader O {
 /					r
 <other listed files generated by full-learning mode>   rwcdx
}

"O" は Subject モードに追加できる様々なフラグの内の一つです。他に使えるフラグは:

A 	Protect the shared memory of this subject. No other processes but processes contained within this subject may access the shared memory of this subject.
C 	Auto-kill all processes belonging to the attacker's IP address upon violation of security policy.
K 	When processes belonging to this subject generate an alert, kill the process.
O 	Allow loading of writable libraries.
T 	Deny execution of binaries or scripts that are writable by any other subject in the policy. This flag is evaluated at policy enable time. All binaries with execute permission that are writable by another subject (ignoring special roles) will be reported and the RBAC system will not allow itself to be enabled until the changes are made.

このリンク を見て下さい。

他の機能

ファイルシステム保護

chroot やファイルシステムの悪用と戦う

Grsecurity にはユーザーがシステムに関する不必要な情報を得るのを禁止する多数のパッチが含まれています。ptrace システムコールや chroot の使用の制限もあります。

セキュリティメカニズムを切り替える

/etc/sysctl.d/05-grsecurity.conf 設定ファイルを使うことで起動時に様々なセキュリティ機能を有効化・無効化することができます。詳しい情報は、sysctl を見て下さい。

カーネル監査

システムのログ機能を拡張する

grsecurity はカーネルに関係するログ機能に機能を追加します。grsecurity の Kernel Auditing によって、カーネルはアプリケーションが起動したりデバイスが（アン）マウントされたりしたときに通知を行います。

プロセス制限

ノート: linux-grsec パッケージはデフォルトでは厳格な /proc 制限を有効にしません。代わりに、hidepid=2 マウントオプションを /proc で設定することで他のユーザーのプロセスを隠すことができます。これは cgroup ファイルシステムの制限を回避するための一時的なハックなので systemd に破壊を生じさせます。

ネットワーク保護

Linux の TCP/IP スタックは予測攻撃に対して脆弱です。grsecurity にはこうした攻撃に対抗するためのランダム化パッチが含まれています。さらに、特定のグループのネットワークアクセスを無効化するソケット制限を有効にすることもできます。