他の人がセッションログに書き戻すのを防ぐ

他の人がセッションログに書き戻すのを防ぐ

監査の目的で、各ユーザーセッションのコマンド履歴を新しいファイルに保存する回避策を実装しました。したがって、各セッションファイルは開始時間とユーザー名によって識別されます。

質問:セッションユーザーはファイル所有者なので、ファイルを変更または削除することもできます。

ファイルがいっぱいになるとファイルが変更されるのを防ぐ方法はありますか?それはまるで一度書いてそしてそれはロックされています。

答え1

あなたが提案したものは、標準ツールを使用して正しく実行することはほとんど不可能です。

ご存知のように、コマンド履歴の保存は通常、ファイルがユーザーの所有であり、ユーザーが自由に削除、消去、または編集できるため、機能しません。コマンド履歴ファイルを信頼できるプロセスによって読み取られるパイプにすることでこの問題を解決できますが、ユーザーが履歴ファイルを閉じたり他の場所を指すのを防ぐ方法はありません。

強制コマンドロギング(パイプ、ソケット、またはsyslogを介して他のプロセスにログを送信)を使用して新しいシェルを作成すると、これを防ぐことができますが、ユーザーは通常のシェル、Perl、Pythonインタプリタなどを実行して問題を解決できます。ロギングの問題。子プロセスが実行するアクションをログに記録するには、セッション全体をラップするか、script同様にユーザーが見るすべてをログに記録する必要があります。それでも端末に印刷せずにコードをダウンロードして実行することができます。ユーザーがランダムなプログラムを実行できないようにすると、そのようになりますが、最も便利な操作も実行できなくなります。シェルやPerlスクリプトが実行されないようにすると、多くの一般的なツールも機能しなくなります。

シェルやその他のユーティリティがツールであることを考慮すると、この結果は驚くべきことではありません。~のため代わりにユーザー反対するそれらを。

straceユーザーのセッションをラッパーまたは同様のものとして予約することで、プロセスとシステムのすべての対話を見ることができますが、長いセッションでstraceログを読み取るのは面白いことではありません。

また、あなたのユーザーがこのレベルの監視に反対すると思います。私もそうでしょう。

答え2

設定についてもっと知らないと、良い答えをするのは難しいかもしれませんが、それをサポートするファイルシステム(例:ext3)を使用すると仮定し、ログファイルを「追加のみ」としてマークすると、何かを達成する方法のように聞こえます。 、使用chattr +a <file>

このプロパティを設定または設定解除するには特別な権限が必要です。その場合はファイルのみを添付できます。これにより、ユーザーがファイルにランダムなデータを追加するのを防ぐことはできませんが、すでに存在するデータを削除するのを防ぎます。

関連情報