UNIX エンドポイント管理ガイド › パフォーマンスの向上 › Global Access Check の使用 › GAC の制限事項

GAC の制限事項

ファイルへのアクセス件数が毎秒数百にも及ぶ場合は、GAC を実装するとパフォーマンスが向上します。このことはすでに立証されていますが、以下のような制限事項があります。

• デフォルトでは、GAC のルールは root ユーザ（通常は ADMIN）に適用されません。 root ユーザにルールを適用できるようにするには、seos.ini ファイルの［SEOS_syscall］セクションにある以下のトークンを設定します。

  GAC_root=1
  

  このトークンのデフォルト値は 0（ゼロ）です。 デフォルトに戻すには、トークンを 0（ゼロ）に設定するか、このトークンを削除します。

• 条件付きで保護されるファイル ルール（日付や時間帯の制限、Program Pathing など）をテーブルに含めることはできません。 GAC.init ファイルにこのようなファイル ルールを指定しても、日付や時間の制限およびその他の制限は適用されません。
• audit（ALL）属性または audit（success）属性を指定したファイル ルールを GAC.init ファイルに含めることはできません。 GAC.init ファイルにこのようなファイル ルールを指定した場合、成功したアクセスの監査は記録されません。
• フィルタ処理プロセスでは、実際の（現在の）UID（つまり、実行時のプロセスに関連付けられた UID）が使用されます。 これは、現在の UID ではなく元の UID（ユーザがログイン時に使用した UID）を CA Access Control で追跡する場合にループホールとなります （CA Access Control では、UID 使用状況の追跡を実行して、責任の所在をいっそう明確にするセキュリティを実現しています）。

  ここでは例を挙げて、このループホールがどのように悪用されているかを説明します。 ユーザ Tony には、Accounts/tmp ファイルへのアクセス権がありません。 そのため Tony は、Accounts/tmp へのアクセスを許可されているユーザ Sandra の代理になります（/bin/su を使用します）。 Sandra がすでに Accounts/tmp ファイルにアクセスしている場合、このファイルは Sandra の UID と共に do-not‑call‑me テーブルに追加されています。 したがって、Sandra の UID を使用している Tony にもファイルへのアクセスが許可されます。 これは、カーネル コードに UID の履歴が保持されないためです。

  一方、Sandra がそれまでにファイルにアクセスしていない場合は、seosd を使用して通常どおりアクセス許可のチェックが行われ、Tony のファイルへのアクセスは拒否されます。 このようなループホールを防止するために、ADMIN ユーザはデータベースの SURROGATE オブジェクトを保護する必要があります。 この例の場合、ADMIN ユーザは以下のルールをデータベースに追加できます。

  newres SURROGATE USER.Sandra default(N) owner(nobody)
  

  このコマンドを実行すると、Tony が su コマンドを使用して Sandra のアクセス権限を取得することはできなくなります。

• アクセサが root の場合、キャッシュ メカニズムは影響しません。 これは、データベースをクエリしなければ root にアクセス許可が与えられないためです。