これを読んでいると、次のエクスプロイトが見つかりました。

% cp /usr/bin/id ~
% chmod -x ~/id
% ls -al ~/id
-rw-r--r-- 1 edd edd 22020 2012-08-01 15:06 /home/edd/id
% ~/id
zsh: permission denied: /home/edd/id
% /lib/ld-linux.so.2 ~/id
uid=1001(edd) gid=1001(edd) groups=1001(edd),1002(wheel)

このスニペットは、通常の非特権ユーザーとしてファイルシステムの実行許可を簡単に回避できることを示しています。これをUbuntu 12.04で実行しました。

Linuxローダーはfile（1）によると共有オブジェクトですが、直接実行できるエントリポイントもあります。この方法で実行されると、LinuxローダーはELFバイナリのインタープリターとして機能します。

ただし、私のOpenBSDマシンでは、ローダーをプログラムとして実行できないため、このエクスプロイトは効果的ではありません。OpenBSDのマニュアルページには、「ld.so自体が、カーネルによって最初にロードされる共有オブジェクトです」と書かれています。

これをSolaris 9で試してみると、セグメンテーション違反が発生します。他の場所で何が起こるかわかりません。

したがって、私の質問は次のとおりです。

• なぜ（直接実行）のLinuxローダはないではない ELFバイナリを解釈する前に、ファイルシステム属性をチェック！
• ファイルの実行を許可しないように設計されたメカニズムを実装するのはなぜですか？私は何かを見逃しましたか？

execute許可の目的は、一般的な実行を妨げることではありません。（1）実行するファイルをプログラムに伝えること、および（2）setuidビット（など）が指定されている場合に、特権ユーザーとしての実行を防ぐことです。

リンカハックは、見かけ以上に悪用されていません。さらに簡単に読み取るためのアクセス許可を持っている任意の非実行可能ファイルを実行できます。

$ cp unexecutable_file ~/runme
$ chmod +x ~/runme
$ ~/runme

Arch Linuxフォーラムでこの議論を参照してください。

要約すれば：

実行する必要があるファイルのマーク付け

シェルスクリプトを記述するとき、を使用して実行可能としてマークできますchmod +x。これは、実行可能にすることをシェルに示唆します（それ以外の場合は、シェルが知っている限り、単なるプレーンテキストファイルです）。シェルは、を入力すると、タブ補完でそれを表示できます./Tab。

同様に、something.dディレクトリ（例init.d：）には、通常デーモンによって自動的に実行される起動または制御シェルスクリプトが含まれます。ディレクトリにコメントまたはREADMEファイルをプレーンテキストファイルとして配置することもできます。または、スクリプトの1つを一時的に無効にすることもできます。これを行うには、その特定のファイルの実行ビットをクリアします。これは、デーモンにスキップするよう指示します。

特権実行の防止

このsetuidビットは、ファイルを実行すると、指定されたユーザー（rootなど）として実行されることを意味します。

フォーラムの投稿はそれをうまく説明しています：

特定のユーザーの実行可能ファイルをsetuidにしたいが、特定のグループのユーザーだけがsetuidとして実行できるようにしたい。コピーして実行することはできますが、setuidフラグは失われるため、元のファイルを所有したユーザーではなく、自分自身として実行されます。

ファイルへの読み取りアクセス権がある場合は、いつでもコピーを作成できます。

個人用コピーを作成できる場合は、そのコピーを実行可能として常にマークできます。

これはld-linuxの動作を説明するものではありませんが、非常に有用なセキュリティの抜け穴ではないことを示しています。

より強固なセキュリティが必要な場合は、SELinuxを検討してください

質問の見方を少し変えると、Mechanical Snailが言うように、ファイルの実行許可は実行を妨げることを意図したものではありません。ただし、ファイルシステムオプション「noexec」は実行を防止し、それほど簡単に回避されません（すべてのファイルシステムでサポートされているわけではありませんが、最も一般的なLinuxシステムでは確実にサポートされています）。管理者がユーザーが独自のプログラムを実行できないようにしたい場合は、homeディレクトリとtmpディレクトリ、およびユーザーがファイルを作成できる他のディレクトリでnoexecオプションを指定できます。

$ mount -o noexec /dev/sdd1 /test
$ cd /test
$ cp /usr/bin/id .
$ ./id
-bash: ./id: Permission denied

どうやら、質問で言及されたローダーのトリックを使用してnoexecオプションを回避することが可能でしたが、それはいくつかのバージョンのカーネルで修正されました。

から http://linux.die.net/man/8/mount：

noexec

マウントされたファイルシステム上のバイナリの直接実行を許可しないでください。（最近まで/lib/ld*.so / mnt / binaryのようなコマンドを使用してバイナリを実行できました。このトリックはLinux 2.4.25 / 2.6.0以降で失敗します。）