スクリプトでsetuidを有効にするとセキュリティの問題が発生するため、デフォルトでは無効になっていますが、実行可能ファイルで機能することを期待しています。この投稿で説明されている指示に従って、出力としてuidを示す実行可能ファイルを作成しました。 シェルスクリプトでsetuidを許可する
しかし、runningSudo chmod +s ./setuid-test
の前後で同じuid(1000)を返します。これは、setuidが実行可能ファイルに影響を与えないことを意味すると思います。なぜ、どのように解決するのですか?
ソースコード:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char** argv) {
printf("%d", geteuid());
return 0;
}
構築して実行
$ gcc -o setuid-test setuid-test.c
$ ./setuid-test
1000
$ Sudo chown nobody ./setuid-test; Sudo chmod +s ./setuid-test
$ ./setuid-test
1000
ls -la
を実行すると、次のようになります。
me@me:~$ ls -la setuid-test
-rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test
Unix/Linux用に設計されたほとんどのファイルシステムは、nosuid
属性を使用してマウントできます。これにより、これらのファイルシステムにあるsetuidまたはsetgidバイナリがプロセスの有効なuidまたはgidを変更するのを防ぎます。管理者以外の管理下にある「信頼できない」ファイルシステムをマウントするときによく使用されます。
あなたの場合、使用しているファイルシステムはタイプecryptfsで、これは askubuntu:バイナリを暗号化されたホームディレクトリの下でroot setuidで実行するとエラー から、nosuid(およびnodev)が自動的に適用されます数年前。
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409 からの変更理由の説明は次のとおりです。
ヴィンセントダネン2012-07-20 11:25:56 EDT
setuid-rootであるプライベートecryptfsマウントヘルパー(/sbin/mount.ecryptfs_private)により、権限のないローカルユーザーがユーザー制御のecryptfs共有をローカルシステムにマウントできることが報告されました。 ecryptfsヘルパーは「nosuid」および「nodev」フラグを使用してファイルシステムをマウントしないため、ユーザーはsetuid-rootバイナリやデバイスファイルを含むファイルシステムをマウントして、権限の昇格を引き起こす可能性があります。これは、ユーザーがシステムに物理的にアクセスできる場合、USBデバイスを介して行うことができます。
...
強制MS_NOSUIDおよびMS_NODEVマウントフラグがバージョン99に追加されました。
実行可能ファイルのSetUIDビットは、ファイルowner(スーパーユーザーではない)で実行可能ファイルを実行することを許可します。 rootとして実行可能ファイルを実行できるようにするには、以下を実行します。
Sudo chown 0:0 ./setuid-test