Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. I 認証
    1. 2 PAM を利用した認証
    2. 3 NIS の使用
    3. 4 YaST を利用した認証クライアントの設定
    4. 5 389 Directory Server を利用した LDAP サービス
    5. 6 Kerberos を利用したネットワーク認証
    6. 7 Active Directory サポート
    7. 8 FreeRADIUS サーバの構築
  4. II ローカルセキュリティ
    1. 9 物理的なセキュリティ
    2. 10 ソフトウエア管理
    3. 11 ファイルの管理
    4. 12 パーティションやファイルの暗号化
    5. 13 cryptctl を利用したアプリケーション向けのストレージ暗号化
    6. 14 ユーザ管理
    7. 15 cronat の制限
    8. 16 Spectre/Meltdown チェッカー
    9. 17 YaST を利用したセキュリティの設定
    10. 18 Polkit 認可フレームワーク
    11. 19 Linux でのアクセス制御リスト
    12. 20 AIDE を利用した侵入検知
  5. III ネットワークセキュリティ
    1. 21 X Window System と X 認証
    2. 22 OpenSSH によるネットワーク操作の機密保持
    3. 23 マスカレードとファイアウオール
    4. 24 VPN サーバの設定
    5. 25 X Window System で動作する PKI マネージャ XCA による管理
    6. 26 sysctl 変数によるネットワークセキュリティの改善
  6. IV AppArmor による権限の制限
    1. 27 AppArmor の紹介
    2. 28 入門
    3. 29 プログラムに対する予防接種
    4. 30 プロファイルのコンポーネントと文法
    5. 31 AppArmor のプロファイルリポジトリ
    6. 32 YaST を利用したプロファイルの構築と管理
    7. 33 コマンドラインからのプロファイル構築
    8. 34 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 35 pam_apparmor によるユーザの制限
    10. 36 プロファイルを作成したアプリケーションの管理
    11. 37 サポート
    12. 38 AppArmor 用語集
  7. V SELinux
    1. 39 SELinux の設定
  8. VI Linux 監査フレームワーク
    1. 40 Understanding Linux audit
    2. 41 Linux 監査フレームワークの設定
    3. 42 監査ルールセットの紹介
    4. 43 その他の情報源
  9. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.6

42 監査ルールセットの紹介 Edit source

下記の設定例では、どのようにして監査システムからお使いのシステムを監視することができるのかについて説明しています。また、 Controlled Access Protection Profile (CAPP) で指定されている監査対象のイベントをカバーするのに必要な項目について、主なものを紹介しています。

ルールセットの例は下記のようなパーツから構成されています:

下記に示す設定例を、実際に使用する設定ファイルに変換するには、下記の手順を実施してください:

  1. まずはお使いの環境に合った設定を選んで、必要に応じて調整を行ってください。

  2. 下記の設定例から、 /etc/audit/audit.rules ファイルに対してルールを追加していってください。このとき、必要に応じてルールを変更してもかまいません。

注記
注記: 監査ログレベルの調整について

お使いの環境の要件にあわせることなく、設定例をそのまま使用して監査を行うことは避けてください。まずは何を監査するのか、どの範囲まで監査するのかを決定してから実施してください。

audit.rules ファイルは auditctl コマンドの集合体であると考えられます。このファイルの各行は、それぞれ auditctl のコマンドラインとして解釈されます。そのため、このルールファイル内で使用する文法は、 auditctl のコマンドラインと同じです。

42.1 基本的な監査設定パラメータの追加 Edit source

-D1
-b 81922
-f 23

1

新しくルールセットを定義するため、既存のルールを全て削除しています。

2

監査メッセージを受け付けるためのバッファ数を指定しています。お使いのシステムにおける監査ログの量に応じて、増やしたり減らしたりしてください。

3

カーネルが致命的なエラーを処理する際に使用する、失敗フラグを指定しています。指定可能な値は 0 (何もしない), 1 (printk (失敗メッセージを表示する)), 2 (パニックモード、システムを停止する) のいずれかです。

-D オプションを指定してルールキューをいったん空にすることで、それまでに設定されていたルールによる影響を受けることなく、このファイル内に書かれているルールを正しく適用することができるようになります。また、バッファ数の指定 ( -b ) は、監査システムの負荷を上昇させすぎてシステムに障害が発生したりしないようにするために重要な設定です。このほか、失敗フラグ -f 2 の選択は、お使いのシステムに対して致命的なエラーが発生した際、監査レコードを保全するために必要な設定です。致命的なエラーの際にシステムをシャットダウンすることで、監査から外れたプロセスが現れないようにすることができるためです。このような要件が無い場合は、 1 ( printk ) を選択してください。

重要
重要: 失敗フラグの選択について

本番環境にお使いの監査ルールを適用するにあたっては、あらかじめテスト環境で 想定される最大の負荷 をかけて、監査が正しく動作することをご確認ください。また、 -f 2 フラグを指定しておくことも重要です。この設定は、何らかの閾値を超過した場合に、カーネルをパニック状態 (書き込み待ちのデータを書き込むことなくシステムを即時に停止させる) にすることができる設定です。ただし、 -f 2 の設定は、セキュリティを最重要視する環境でのみお使いください。

42.2 監査ログファイルと設定ファイルに対する監視の追加 Edit source

ご利用の監査設定ファイルとログファイルに対して監視を設定して、設定ファイルやログファイルに対して改ざんを試みた形跡や、不正に読み取ろうとした形跡を記録するようにしておいてください。

注記
注記: ディレクトリとファイルの作成に対する監視について

ディレクトリに対する監視は、ファイルアクセスに対するイベントだけが必要な環境では、特に設定を行う必要はありません。ディレクトリアクセスのイベントは、メタデータの変更を伴うディレクトリの inode 変更の際にのみ発行されるためです。ファイルアクセスに対してイベントを発生させたい場合は、各ファイルを監視対象にしてください。

-w /var/log/audit/ 1
-w /var/log/audit/audit.log

-w /var/log/audit/audit_log.1
-w /var/log/audit/audit_log.2
-w /var/log/audit/audit_log.3
-w /var/log/audit/audit_log.4

-w /etc/audit/auditd.conf -p wa2
-w /etc/audit/audit.rules -p wa
-w /etc/libaudit.conf -p wa

1

監査ログの存在するディレクトリに対して監視を設定しています。このディレクトリに対してアクセスが試みられると、どのような種類のアクセスであってもイベントが発生します。ログのローテーションを使用している場合は、その際にもイベントが発生します。

2

監査の設定ファイルに対して監視を設定しています。このファイルに対する書き込みと、属性変更が記録されるようになります。

42.3 ファイルシステムオブジェクトの監視 Edit source

システムコールに対する監査を行うことで、アプリケーションレベルよりも細かく、お使いのシステムにおける動作を追跡することができるようになります。ファイルシステム関連のシステムコールを追跡することで、お使いのアプリケーションがどのようなシステムコールを使用しているのかを判断することができるほか、その使用が適切であるかどうかを確認することもできます。また、マウントやマウント解除の操作を追跡することで、外部リソース (リムーバブルメディアやリモートのファイルシステムなど) の使用についても追跡を行うことができます。

重要
重要: システムコールの監査について

システムコールの監査を行うと、ログを頻繁に書き込むことになります。そのため、カーネルに対しても重い負荷を与えることになります。監査を行った結果、通常よりも応答が遅くなったと感じた場合は、おそらくシステムのバックログ設定と流量制限の設定を超過したものと思われます。この場合は、監査ルール内にどのシステムコールを含めるのかを慎重に確認し、ログ設定についても調整を行ってください。 40.2項 「Configuring the audit daemon」 では、関連する設定を調整する方法について説明しています。

-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown321

-a entry,always -S creat -S open -S truncate -S truncate64 -S ftruncate -S ftruncate642

-a entry,always -S mkdir -S rmdir3

-a entry,always -S unlink -S rename -S link -S symlink4

-a entry,always -S setxattr5
-a entry,always -S lsetxattr
-a entry,always -S fsetxattr
-a entry,always -S removexattr
-a entry,always -S lremovexattr
-a entry,always -S fremovexattr

-a entry,always -S mknod6

-a entry,always -S mount -S umount -S umount27

1

ファイルの所有権とパーミッションを変更する操作に関連するシステムコールに対して、監査コンテキストを有効化しています。お使いのハードウエアアーキテクチャによっても異なりますが、 *32 のルールが必要となる環境と不要な環境があります。 AMD64/Intel 64 のような 64 ビットシステムでは、 *32 のルールは削除する必要があります。

2

ファイルの内容変更に関連するシステムコールに対して、監査コンテキストを有効化しています。お使いのハードウエアアーキテクチャによっても異なりますが、 *64 のルールが必要となる環境と不要な環境があります。 AMD64/Intel 64 のような 64 ビットシステムでは、 *64 のルールは削除する必要があります。

3

ディレクトリの作成や削除など、ディレクトリ操作に対する監査コンテキストを有効化しています。

4

シンボリックリンクの作成やハードリンクの作成、削除や名前変更などのリンク操作に対して、監査コンテキストを有効化しています。

5

ファイルシステムの属性操作に関する監査コンテキストを有効化しています。

6

デバイスファイルを作成するための mknod システムコールに対して、監査コンテキストを有効化しています。

7

マウントやマウント解除の操作に対して、監査コンテキストを有効化しています。 x86 アーキテクチャの場合は umount のルールを、 Intel 64 アーキテクチャの場合は umount2 のルールをそれぞれ無効化してください。

42.4 セキュリティ設定ファイルとデータベースの監視 Edit source

お使いのシステムに対して望ましくない行為をさせないようにするため、 cronat の設定ファイルのほか、ジョブスケジュールの変更を行おうとする行為を追跡しておくことをお勧めします。このほか、ユーザやグループ、パスワードやログインデータベースやアクセスログなどへの書き込みアクセスについても追跡することで、お使いのシステムのユーザデータベースを改ざんしようとする行為を検出できるようになります。

また、お使いのシステムにおける設定 (カーネル, サービス, 時刻など) に対する変更を追跡しておくことで、お使いのシステムにおける重要な機能の改ざんを防ぐことができます。特に PAM の設定ファイルの変更は、認証スタックの設定変更は管理者以外から行われるべきではないことから、監視対象としておくべきです。また、アプリケーション側からの PAM の使用状況や用途についても、ログに記録を行っておくべきです。このほか、機密を確保しておくべき認証や通信にかかわる設定ファイルについても、同様に監視対象としておくのがよいでしょう。

1
-w /var/spool/atspool
-w /etc/at.allow
-w /etc/at.deny

-w /etc/cron.allow -p wa
-w /etc/cron.deny -p wa
-w /etc/cron.d/ -p wa
-w /etc/cron.daily/ -p wa
-w /etc/cron.hourly/ -p wa
-w /etc/cron.monthly/ -p wa
-w /etc/cron.weekly/ -p wa
-w /etc/crontab -p wa
-w /var/spool/cron/root

2
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow

-w /etc/login.defs -p wa
-w /etc/securetty
-w /var/log/lastlog

3
-w /etc/hosts -p wa
-w /etc/sysconfig/
w /etc/init.d/
w /etc/ld.so.conf -p wa
w /etc/localtime -p wa
w /etc/sysctl.conf -p wa
w /etc/modprobe.d/
w /etc/modprobe.conf.local -p wa
w /etc/modprobe.conf -p wa
4
w /etc/pam.d/
5
-w /etc/aliases -p wa
-w /etc/postfix/ -p wa

6
-w /etc/ssh/sshd_config

-w /etc/stunnel/stunnel.conf
-w /etc/stunnel/stunnel.pem

-w /etc/vsftpd.ftpusers
-w /etc/vsftpd.conf

7
-a exit,always -S sethostname
-w /etc/issue -p wa
-w /etc/issue.net -p wa

1

atcron の設定ファイルと、ジョブのスケジュール設定、そしてそれらのイベントに対するラベルの割り当てに対して、それぞれ監視を設定しています。

2

ユーザ, グループ, パスワード, ログインデータベースに対して監視を設定しているほか、たとえばログインの失敗など、ログイン関連のイベントを記録し、ラベルでわかりやすく識別するように設定しています。

3

まずはホスト名の設定を行っている /etc/hosts に対して、監視を設定しラベルを指定しています。また、 /etc/sysconfig というシステム設定ディレクトリに対しても、変更を追跡しています。それぞれのファイルイベントを追跡したい場合は、ファイルごとの監視を設定してください。さらに、 /etc/init.d ディレクトリ内にある起動設定の変更に対しても、監視を設定しラベルを指定しています。こちらについても同様に、それぞれのファイルイベントを追跡したい場合は、ファイルごとの監視を設定してください。また、 /etc/ld.so.conf というリンカの設定ファイル、 /etc/localtime というローカル時刻の設定ファイルについても、監視とラベルを設定しています。このほか、 /etc/sysctl.conf , /etc/modprobe.d/ , /etc/modprobe.conf.local , /etc/modprobe.conf にあるカーネルの設定ファイルに対しても、監視とラベルを設定しています。

4

PAM の設定ファイルのディレクトリに対して監視を設定しています。このディレクトリ内にあるファイルを監視したい場合は、それぞれのファイルに対して監視を設定してください。

5

postfix の設定ファイルに対して監視を設定し、書き込みや属性変更を行おうとした場合に、後から検索できるようラベルを指定して記録を行っています。

6

SSH, stunnel , vsftpd の各設定ファイルに対して、後から検索できるようラベルを指定して監視を設定しています。

7

sethostname システムコールに対して監査を設定するほか、 /etc/issue/etc/issue.net にあるシステムの識別情報の設定ファイルに対して、後から検索できるようラベルを指定して監視を設定しています。

42.5 その他のシステムコールに対する監視 Edit source

42.3項 「ファイルシステムオブジェクトの監視」 で説明しているファイルシステム関連のシステムコールの監査だけでなく、その他のシステムコールに対しても追跡を行うことができます。たとえばタスク (プロセス) の作成を追跡することで、アプリケーションの振る舞いを理解する手助けになったりすることがあります。また、 umask システムコールを監査することで、プロセスがどのような作成マスクを使用しているのかを調べたりすることもできます。また、システム時刻の変更に関わるシステムコールを追跡することで、誰かがシステムの時刻を改ざんしようとしていないかどうかを確認することもできます。

1
-a entry,always -S clone -S fork -S vfork

2
-a entry,always -S umask

3
-a entry,always -S adjtimex -S settimeofday

1

タスク (プロセス) の作成を追跡する設定です。

2

umask システムコールに対して監査コンテキストを追加しています。

3

システム時刻の変更に関わるシステムコールの追跡です。 adjtimex はシステムの時刻調節の設定を行うためのシステムコールで、 settimeofday は絶対時刻を設定するためのシステムコールです。

42.6 システムコールのパラメータでのフィルタリング Edit source

42.3項 「ファイルシステムオブジェクトの監視」42.5項 「その他のシステムコールに対する監視」 で説明しているシステムコールの監査に加えて、さらに高度にアプリケーションの動作を追跡することができます。具体的にはフィルタを設定することで、監査の範囲を絞り込むことができるようになります。本章では、多重化を伴わないシステムコールのほか、 socketcall や ipc などのように、多重化を伴うシステムコールのパラメータに対して、フィルタリングを設定する方法を紹介しています。なお、 AMD64/Intel 64 など、 64 ビット環境では、 socketcall も ipc も多重化されません。

重要
重要: システムコールの監査について

システムコールの監査を行うと、ログを頻繁に書き込むことになります。そのため、カーネルに対しても重い負荷を与えることになります。監査を行った結果、通常よりも応答が遅くなったと感じた場合は、おそらくシステムのバックログ設定と流量制限の設定を超過したものと思われます。この場合は、監査ルール内にどのシステムコールを含めるのかを慎重に確認し、ログ設定についても調整を行ってください。 40.2項 「Configuring the audit daemon」 では、関連する設定を調整する方法について説明しています。

access システムコールは、ファイルやファイルシステムのオブジェクトに対して、読み込みや書き込み、存在のチェックの機能を提供するシステムコールです。 -F フィルタフラグを設定することで、特定の条件に該当するシステムコールのみを記録することができるようになります。具体的な書式は -F a1=アクセスモード です。 access システムコールにおけるパラメータについて、詳しくは /usr/include/fcntl.h ファイルをお読みください。

-a entry,always -S access -F a1=41
-a entry,always -S access -F a1=62
-a entry,always -S access -F a1=73

1

access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( モード ) が 4 ( R_OK )の場合にのみ、監査を行う指定です。このルールフィルタでは、ユーザやプロセスがアクセスしようとしているファイルやファイルシステムのオブジェクトが、読み込みのための権限を持っているかどうかをテストする際に、監査を行う指定です。

2

access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( モード ) が 6 、つまり 4 (R_OK) および 2 (W_OK) の場合にのみ、監査を行う指定です。このルールフィルタでは、読み込みおよび書き込みのための権限を持っているかどうかをテストする際に、監査を行う指定です。

3

access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( モード ) が 7 、つまり 4 (R_OK) および 2 (W_OK) および 1 (X_OK) の場合にのみ、監査を行う指定です。このルールフィルタでは、読み込みおよび書き込み、そして実行のための権限を持っているかどうかをテストする際に、監査を行う指定です。

socketcall システムコールは多重化型のシステムコールです。多重化とは複数のシステムコールを 1 つのシステムコールで賄う仕組みで、 libc 側で実際のシステムコールを最初のパラメータ ( a0 ) として設定する仕組みです。 socketcall で利用できるシステムコールについては、マニュアルページをお読みください。また、パラメータの値とシステムコールの名前の一覧については、 /usr/src/linux/include/linux/net.h ファイルをお読みください。監査システムでは、 -F a0=システムコール番号 の形式で、システムコールを指定することができます。

-a entry,always -S socketcall -F a0=1 -F a1=101
## x86_64, ia64 アーキテクチャの場合は下記をお使いください
#-a entry,always -S socket -F a0=10

-a entry,always -S socketcall -F a0=52
## x86_64, ia64 アーキテクチャの場合は下記をお使いください
#-a entry, always -S accept

1

socket(PF_INET6) システムコールを監査しています。 -F a0=1 は socket システムコールを指し、 -F a1=10 は IPv6 プロトコルファミリ (PF_INET6) を指定した場合を意味するパラメータになります。最初のパラメータ ( a0 ) に対応する値は /usr/include/linux/net.h ファイルを、 2 つ目のパラメータ ( a1 ) に対応する値は /usr/src/linux/include/linux/socket.h ファイルをそれぞれお読みください。 AMD64/Intel 64 などの 64 ビットプラットフォームでは、 socketcall システムコールによる多重化は行っていませんので、これらの環境ではシステムコール名を直接指定してください。

2

上記と同様に socketcall システムコールを監査していますが、 a0=5 は accept システムコールを意味しています (詳しくは /usr/include/linux/net.h をお読みください) 。 AMD64/Intel 64 などの 64 ビットプラットフォームでは、 socketcall システムコールによる多重化は行っていませんので、これらの環境ではシステムコール名を直接指定してください。

ipc システムコールは多重化されるシステムコールのもう 1 つの例となります。実際のシステムコールは ipc システムコールの 1 つ目のパラメータとして指定されます。このようにしてフィルタを設定することで、特定の ipc システムコールのみを監査することができます。値の意味について、詳しくは /usr/include/linux/ipc.h をお読みください。

1
## msgctl
-a entry,always -S ipc -F a0=14
## msgget
-a entry,always -S ipc -F a0=13
## x86_64, ia64 アーキテクチャの場合は下記をお使いください
#-a entry,always -S msgctl
#-a entry,always -S msgget

2
## semctl
-a entry,always -S ipc -F a0=3
## semget
-a entry,always -S ipc -F a0=2
## semop
-a entry,always -S ipc -F a0=1
## semtimedop
-a entry,always -S ipc -F a0=4
## x86_64, ia64 アーキテクチャの場合は下記をお使いください
#-a entry,always -S semctl
#-a entry,always -S semget
#-a entry,always -S semop
#-a entry,always -S semtimedop

3
## shmctl
-a entry,always -S ipc -F a0=24
## shmget
-a entry,always -S ipc -F a0=23
## x86_64, ia64 アーキテクチャの場合は下記をお使いください
#-a entry,always -S shmctl
#-a entry,always -S shmget

1

IPC SYSV メッセージキューに関連するシステムコールを監査しています。この場合、 a0 の値は msgctl ( 14 ) と msgget (13 ) のシステムコールを指しています。 AMD64/Intel 64 などの 64 ビットプラットフォームでは、 ipc システムコールによる多重化は行っていませんので、これらの環境ではシステムコール名を直接指定してください。

2

IPC SYSV メッセージセマフォに関連するシステムコールを監査しています。この場合、 a0 の値は semctl ( 3 ), semget ( 2 ), semop ( 1 ), semtimedop ( 4 ) の各システムコールを指しています。上記と同様に、 AMD64/Intel 64 などの 64 ビットプラットフォームでは、 ipc システムコールによる多重化は行っていませんので、これらの環境ではシステムコール名を直接指定してください。

3

IPC SYSV 共有メモリに関連するシステムコールを監査しています。この場合、 a0 の値は shmctl ( 24 ), shmget ( 23 ) の各システムコールを指しています。これまでと同様に、 AMD64/Intel 64 などの 64 ビットプラットフォームでは、 ipc システムコールによる多重化は行っていませんので、これらの環境ではシステムコール名を直接指定してください。

42.7 キーを利用した監査イベントレコードの管理 Edit source

イベントを生成するためのルールを複数設定し、ログに出力するようにした場合、ログには一般に多くの項目が出力されることになり、必要なものを識別するだけでも手間がかかってしまいます。 ausearch コマンドを使用することで、様々な条件を指定して検索を行うことができます。たとえば ausearch -m メッセージの種類 のように指定すると、メッセージの種類を指定して検索を行うことができます。しかしながら、同じようなメッセージを出力するようなルールが複数あって、それらを区別して扱いたい場合、 /etc/audit/audit.rules ファイルのルール内に、あらかじめ何らかの検索用のキーを指定しておくことができます。このキーはその条件に合致してログを出力する際、必ず書き込まれる仕組みになっています。そのため、ログを記録したあとから ausearch -k キー名 のようにして検索することで、特定のキーが設定されたイベントのみを抽出することができるようになります。

例として、下記のようなルールをルールセットに追加したものします:

-w /etc/audit/audit.rules -p wa

キーを指定しない場合、まずは SYSCALLPATH のイベントのみを抽出してから、さらに grep などのツールを利用して必要な項目を抜き出すような処理が必要になります。そのため、下記のように -k オプションを指定して、キーを書き込むように設定します:

-w /etc/audit/audit.rules -p wa -k CFG_audit.rules

キーには任意の文字列を指定することができます。また、上記の例のように、CFG は設定ファイル用、 LOG はログファイル用等のように設定し、その後ろに実際のファイル名を続けるようにして、わかりやすくするとよいでしょう。上記のようなキーを設定した場合、検索は下記のようになります:

ausearch -k CFG_audit.rules
----
time->Thu Feb 19 09:09:54 2009
type=PATH msg=audit(1235030994.032:8649): item=3 name="audit.rules~" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=2 name="audit.rules" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=1  name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=0  name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1235030994.032:8649):  cwd="/etc/audit"
type=SYSCALL msg=audit(1235030994.032:8649): arch=c000003e syscall=82 success=yes exit=0 a0=7deeb0 a1=883b30 a2=2 a3=ffffffffffffffff items=4 ppid=25400 pid=32619 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="vim" exe="/bin/vim-normal" key="CFG_audit.rules"
このページを印刷