GAC の制限事項

ファイルへのアクセス件数が毎秒数百にも及ぶ場合は、GAC を実装するとパフォーマンスが向上します。このことはすでに立証されていますが、以下のような制限事項があります。
cminderpim14jp
ファイルへのアクセス件数が毎秒数百にも及ぶ場合は、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 ControlMinder で追跡する場合にループホールとなります (CA ControlMinder では、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 にアクセス許可が与えられないためです。