Linuxでユーザーが作成した実行可能ファイルを追跡するにはどうすればよいですか?


11

Linuxを使用して、コマンドライン全体(実際には、すべてのexec *()が自分のユーザーとして実行されます)を含め、自分の名前で実行された実行可能ファイルを追跡したいと思います。私が制御しないプログラムは、タスクを処理するために、渡したプログラムを実行することを想定していますが、それを確実に実行し、どのようなオプションを使用するかを確認します。私が制御しないプログラムは卑劣であり、タスクに対して実行することになっているプログラムの名前に応じて動作を変更するようですので、情報をログに記録して実際のプログラムを呼び出すシェルスクリプトを渡すことができませんプログラム。

Linuxのシステムで自分のユーザーとして実行されたすべてのexec *()を、完全なコマンドラインを含めて通知することはできますか?psつまり、ループでの実行に不足しています。作業しているシステムで直接実行し、ルートアクセスは必要ありませんが、必要に応じて、ルートアクセスが可能なシステムを起動し、プログラムをインストールして調査できます。

Ubuntu 12.4 LTSを使用します。


これは本当のUbuntuの質問よりもUnix / Linuxの質問であるため、Ask Ubuntuではなく、ここで質問します。
Pierre Lebeaupin 2013

1
プログラムはどのくらい卑劣ですか?デバッガーを検出またはバイパスしようとしますか?動的にリンクされていますか?それが卑劣すぎる場合は、ルートになっている仮想マシンを使用する必要があるかもしれません。(これは、特に卑劣なプログラムではない場合でも、最も単純な戦略になる可能性があります。)
Gilles 'SO- stop

@ギレスそれは確かに可能性があります、私はVMを試し、それが実行可能であることが判明した場合は質問を更新します。
Pierre Lebeaupin 2013

注:実際にプログラム名と引数が必要であるように見えますがaudit、シェルの「コマンドライン全体」は、リダイレクト/パイピングとenvvar設定を使用して子プロセスに影響を与える可能性があり、置換/拡張、重要でない引用を含む可能性がありますとスペーシング、およびのような制御構造doa && dob
dave_thompson_085

回答:


10

イベントauditdを記録するように構成する必要がありexecveます。RHEL5での例:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]#

アーチの警告は無視します。問題はないようですが、必要に応じて使用-F arch=b64または-F arch=b32設定できます。

上記の結果は次のとおりです。

[root@ditirlns01 ~]# ls /tmp/whatever
ls: /tmp/whatever: No such file or directory
[root@ditirlns01 ~]# grep whatever /var/log/audit/audit.log
type=EXECVE msg=audit(1386797915.232:5527206): argc=3 a0="ls" a1="--color=tty" a2="/tmp/whatever"
type=EXECVE msg=audit(1386797927.133:5527241): argc=3 a0="grep" a1="whatever" a2="/var/log/audit/audit.log"
[root@ditirlns01 ~]#

それは明らかに速くて汚いですが、それはあなたがそれを行う方法の基本です。正確に何をする必要があるかは、おそらく正確に何をしようとしているのかに大きく依存します。auditctlコマンドでさまざまなフィルターを使用して監査フローを減らすことができますが、その情報はどれもわからないので、何を含めるかわかりません。より具体的なものが必要な場合は、manページを確認するか、この回答にコメントを投稿することをお勧めします。さらに更新します。

それがあなたを正しい方向に向かわせることを願っています。

編集:

あなたの質問は特定のユーザーを見ることに関係しているので、それを示すことができます:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F euid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

上記と同じですが、execveの有効なユーザーIDで実行しているユーザーのみ16777216がログに記録されます。ユーザーのloginuid値(ユーザーが最初にシステムにログインしたユーザー)を指定する必要がある場合は、auid代わりにフィルターします。

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

AUID / loginuidフィルターは、たとえばユーザーがroot suまたはsudorootにアクセスする場合に役立ちます。その状況では、rootとして多くのものが実行されますが、問題になるのはユーザーが開始したものだけです。auditctlまた、フィルタをスタックして、euidとの両方でフィルタリングできますauid

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216 -F euid=0
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]# ls /tmp/nashly -ltar
ls: /tmp/nashly: No such file or directory
[root@ditirlns01 ~]# grep nashly /var/log/audit/audit.log
type=EXECVE msg=audit(1386798635.199:5529285): argc=4 a0="ls" a1="--color=tty" a2="/tmp/nashly" a3="-ltar"
type=EXECVE msg=audit(1386798646.048:5529286): argc=3 a0="grep" a1="nashly" a2="/var/log/audit/audit.log"

1
「rootアクセス権がないことに注意してください」。(それ以外の場合は、これが適切な答えになります。)
Gilles「SO-邪悪なことをやめ

くそー...とても近い...
Bratchley '12 / 12/13

ありがとう、うまくいきました。apt-getでauditctlをインストールする必要があったことを追加する必要があります。これはUbuntuにプリインストールされていませんでした。
Pierre Lebeaupin 2013

ありがとう。いい例です。しかし、監査ログから終了コードを取得する方法はありますか?
Kaos

0

あなたは簡単なものを求めました。私は例を挙げましたmplayerが、それは他の状況に適応できると思います:

#! /bin/sh
# This executable must be used instead of /usr/bin/mplayer
# do not forget the chmod +x filename...
LOG=/tmp/mplayer.log
echo "$@" >> $LOG
if [ -n "$1" ] && [ -f "$1" ] ; then
        filename="$1"
        echo "$(date "+%F %T") $(basename "$filename")" \
        | tee -a "$(dirname "$filename")/mplayer.log"  >> $LOG
fi
/usr/bin/mplayer "$@"

これは非常に単純であることがわかります。最初の引数を解析します。これはファイルであるため、ログは中央ファイルに作成され、ファイル$LOGに連結されます(ファイルは常にmplayer.log同じディレクトリに同じ名前を持っています)。

したがって、ユーザーは、各ディレクトリで読んだ最新の映画を入手できます。


Qは特に、スクリプトの置換は機能しないと述べました。
dave_thompson_085

可能ですが、これは私の状況に適しています。セキュリティの問題はなく、実行するスクリプトを選択できます。信じられないほど信じられないほど、私はこの最も単純な最も単純な解決策を考えていますが、おそらく他の誰かがオタクだけのものに興味がないことに興味があるでしょう。以前のソリューションの方が安全であることを認めます!
MUYベルギー、2017
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.