特権のないユーザーがファイルの所有権を変更できないのはなぜですか?


15

chown(2)から:

特権プロセス(Linux:CAP_CHOWN機能を持つプロセス)のみがファイルの所有者を変更できます。ファイルの所有者は、ファイルのグループを、その所有者がメンバーである任意のグループに変更できます。特権プロセス(Linux:CAP_CHOWNを使用)は、グループを任意に変更できます。

この制限の理由は何ですか?特権のないユーザーが所有するファイルのファイル所有権を変更できないのはなぜですか(つまり、/ etc / shadowがありません)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

回答:


27

ユーザーがファイルを「放棄」できるようにすることで、OSのさまざまな機能を実行できます。といった:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

8

それはそれを許可しないLinuxのデザイナーの単なる個人的な選択だ-すべての擬似セキュリティ上の理由から、与えられたが、これを許可UNIXシステムがあるので、もっともらしいです。

この機能は、unixの動作が「System-V」(AT&T)またはBerkeleyのunix(BSD)に従うかどうかにかかっていると思います...

言及された他のセキュリティ問題に関しては:

  • setuidを介して別のユーザー(またはルート)になりすます。

    問題なし:「所有者」を変更すると、「setXid」ビット(U / G)がクリアされます

  • 誤ったクラウンを取り消すのに十分な権限がない

    実際には「セキュリティリスク」ではありませんが、ユーザーの変更を許可するシステム上にある可能性があります。所有しているディレクトリにある場合は元に戻すことができます。

  • 他の誰かが特定のファイルを作成したように見せること。

    まだ書き込み可能なディレクトリにあります。つまり、グループまたはすべて(またはACLが使用可能な場合は特に)に書き込み用に開いていない限り、homedirに移動できませんでした。

  • 他のユーザーのアカウントで実行するためのcronジョブのセットアップ。

    繰り返しますが、動作しません-crondirはユーザーが所有しており、他のユーザーが読み取り可能に設定することさえできず、書き込みもできません。

  • 誰でも所有権を変更できる場合、誰でもシステム上の任意のファイルへのアクセス権を変更できます。

    いいえ:ユーザーがそのファイルを含むディレクトリを「所有」している場合のみ。つまり、「passwd」という名前のファイルをrootに渡すことができますが、/ etc /への書き込み許可がない限り、/ etc /に移動できませんでした。

  • 割り当て

    潜在的に有効なポイント- のIFあなたはクォータを使用しますが、あなたが合計アップ場合は、ディスク・スペースをホームディレクトリで検出することは簡単だろうように思えます。唯一の問題は、複数のユーザーが書き込み可能なディレクトリにあります。その場合、多分その「dir」の所有者が行っています。それはかもしれないそれらのシステム上のケースでそのサポートあなたがディレクトリのみでこれを行うことができ、ファイルを「配っ」は、あなた自身"が、そう、私は実際にこれを可能にするシステムにしてきたので、LONGの時間がかかりました正確な制限を覚えていません。

「ファイルを渡す」ことを許可するための「トレードオフ」があることを覚えているようです...例えば-それを許可したシステムでは、Linuxが許可していない他の何かが許可されていましたが、それがオフだったことを思い出せません手...

上記の「答え」は本当の答えではないので、答えとしてマークを外すべきだと思います。ITは設計上の決定であり、トレードオフが何であるかがわかりません。

有効な懸念事項となるセキュリティ問題が上記で提起されていない可能性がありますが、上記の問題は有効ではありません。

IMO、「/ proc」のシステム設定可能な「値」である必要がありますが、一般的に言えば、ほとんどの人はそれほど気にかけないと思います。

強力なニーズがある場合は、「chown」のセキュリティを強化し、それを許可するように変更してから、そのようなポリシーを実装できるようにw / setuid「root」を設定します。


クォータは、場所ではなく、常にファイルの所有権に基づいています。それ以外の場合は、誰かがすべてを維持できます。/tmp
user1686

+1、あなたは気が狂ったようです:)。OpenSolarisシステム(実際にはSystem Vの子孫)では、mountオプションを使用してこれを設定できます(したがって、この設定は、システム設定可能な値の提案に従ってシステム全体でなく、単一のマウントポイントに制限できます):(rstchownデフォルト)ファイル所有者の変更をrootユーザーに制限norstchownし、非特権ユーザーが自分のファイルの所有者を変更できるようにします(元に戻すことはできません)。
WhiteWinterWolf

6

さて、だれかが所有権を変更できれば、だれでもシステム上の任意のファイルにアクセスするために許可を変更できます。これは、マルウェアの観点(sudoが不要)だけでなく、システム管理者の観点からも悪いことです。ユーザーのいずれかがファイルのいずれかを変更できる場合、ファイルのアクセス許可は役に立たない。


2
正しい。質問を修正して、ファイルではなくユーザーが所有するファイルを参照していることを明確にしました。
アレクサンドル

1
@Alexandru:悪意のあるユーザーmyTrojan.shがrootによって所有され、SUIDフラグを持つように変化すると考えてください。
ベンジャミンバニエ

@honk:理にかなっています。
アレクサンドル

5

そのため、ユーザーはファイルシステムのクォータを回避できるためです。100MBのクォータがあり、100MBのクォータがある場合、100MBをアップロードし、chmod a + r、chownして、さらに100MBをアップロードできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.