kcheckpass
以下でデバッグしましたArchlinux
。 (ログインに失敗しましたkcheckpass
)
とにかく私はこの特別な問題が存在しないと信じていますkcheckpass
。
int
main(int argc, char **argv)
{
#ifdef HAVE_PAM
const char *caller = KSCREENSAVER_PAM_SERVICE;
#endif
const char *method = "classic";
const char *username = 0;
#ifdef ACCEPT_ENV
char *p;
#endif
struct passwd *pw;
int c, nfd, lfd;
uid_t uid;
time_t nexttime;
AuthReturn ret;
struct flock lk;
char fname[64], fcont[64];
// disable ptrace on kcheckpass
#if HAVE_PR_SET_DUMPABLE
prctl(PR_SET_DUMPABLE, 0);
最初の行を実行する前に:prctl(PR_SET_DUMPABLE, 0);
ls /proc/$(pidof kcheckpass)/exe -al
lrwxrwxrwx 1 wuyihao wuyihao 0 Jan 16 16:16 /proc/31661/exe -> /cker/src/build/kcheckpass/kcheckpass
実行後:
ls /proc/$(pidof kcheckpass)/exe -al
ls: cannot read symbolic link '/proc/31661/exe': Permission denied
/proc/31661/root
と同じ/proc/31661/cwd
coredump
読み取り権限の間には関連性がない/proc/$PID/exe
修正する
問題を再現する最小例:
#include <sys/prctl.h>
#include <stdio.h>
int main(){
prctl(PR_SET_DUMPABLE, 0);
return 0;
}
アップデート2
kcheckpass
最小限の例test
は次のとおりです。
-rwsr-xr-x 1 root root
答え1
ダンプ可能な属性を削除すると、/proc/<pid>/
ユーザーが所有するファイルとリンクの束は他のプロセスから読み取ることができません。
prctl
マンページ内容は次のとおりです。
ダンプできないプロセスは、以下を介して接続できません。 トラック(2)PTRACE_ATTACH;参照トラック(2)もっと学ぶ。
プロセスをダンプできない場合は、プロセス
/proc/[pid]
ディレクトリ内のファイルの所有権が影響を受けます。工程(5)。
そしてproc
マンページ内容は次のとおりです。
/proc/[pid]
各
/proc/[pid]
サブディレクトリには、以下に説明する擬似ファイルとディレクトリが含まれています。これらのファイルは通常、プロセスの実効ユーザーと実効グループIDによって所有されます。ただし、セキュリティ対策としてプロセスの「dumpable」属性が1以外の値に設定されている場合、所有権はroot:rootに設定されます。
ついに、ptrace
マンページ内容は次のとおりです。
ptrace アクセスモードの確認
カーネルユーザースペースAPI(
ptrace()
タスクだけでなく)のさまざまな部分にはいわゆる「ptraceアクセスモード」チェックが必要です。が決まります。 )。(...)
ptrace アクセス・モード検査に使用されるアルゴリズムは、呼び出しプロセスがターゲット・プロセスでその操作を実行できるかどうかを決定します。 (オープンファイルの場合、
/proc/[pid]
「呼び出しプロセス」はファイルを開いたプロセスであり、対応するPIDを持つプロセスは「宛先プロセス」です。)アルゴリズムは次のとおりです。(...)
- ターゲットプロセスの「dumpable」属性に1(...)以外の値があり、呼び出し元がターゲット
CAP_SYS_PTRACE
プロセスのユーザーネームスペースにその機能を持っていない場合、アクセスは拒否されます。