実行権限の目的は何ですか？
setuid/setgidビットは関係ないとします。なぜ別の実行許可があるのですか？
哲学的には、書き込み権限には読み取り権限が含まれ、読み取り権限には実行権限が含まれているように感じます。もちろん、Linuxではこのようなことは行われず、これが役立つ場合もありますが、ほとんど役に立たないと思います。たとえば、プロセスが実行可能でないファイルを読み取ることができる場合、そのプロセスがディレクトリに書き込むことができる限り、ファイルをそこにコピーし、実行ビットを設定して、そのプログラムを実行するだけです。本当に、読み取り包含は単純なケースで実行されます。ソースファイルにsetuidビットがある場合、またはプロセスがnoexecマウントポイントにしか書き込むことができない場合、これは明らかに正しく機能しません。
私が尋ねる理由は、プロセスがそのメモリの任意のチャンクをexec許可するLinux syscallを実装しているためです。 （特定の使用例は、メインプログラム内にバンドルされた完全なプログラムがあり、execveを呼び出すためにそれをディスクに書きたくない場合です。）そのようなsyscallに深刻な懸念がありますか私が知っておくべきこと？
ご想像のとおり、実行権限が権限として役立つことはほとんどありません。ファイルの属性ではなく許可としてそれを持っていることは、少し歴史的な事故です。ただし、存在するため、なくなることはありません。読み取り権限とは異なる実行権限を持つことは、2つの場合に重要です。
- ファイルの実行により追加の権限が付与される場合、その特定のファイルを実行できるユーザーが重要になります。 setuid、setgid、またはsetcap実行可能ファイルは、誰でも読み取り可能ですが、誰でも実行可能ではありません（多くのディストリビューションでは、機密性がないためにワールド実行可能でなくても、setxidファイルをワールド読み取り可能にします。誰でもディストリビューションからファイルをダウンロードできます。アーカイブ）。
- 一部のアカウントは、実行可能ファイルへのコンテンツの書き込みが許可されないように制限されている場合があります。たとえば、アカウントは
chmodなしで 制限付きシェル にのみアクセスできる場合や、noexecでマウントされたファイルシステム上のディレクトリへの書き込みのみが許可されている場合があります。このようなユーザーは、すでに存在する実行可能ファイルに制限されています。
メモリからexecにシステムコールを追加すると、制限されたアカウントが任意のコードを実行できるようになります。これは、制限されたアカウントであっても、どこからでもアクセスできるネイティブコードインタープリターを持つことと同等です。これはセキュリティ制限を破るため、メインストリームカーネルでは受け入れられません。自分のマシンにデプロイすることもできますが、その影響を念頭に置いてください。
ただし、既存の機能を使用するには、多くの作業とセキュリティの手荷物が必要です。ディスクに書き込むことなくコードを実行することが可能です。 tmpfsなどの非ディスクファイルシステム上のファイルにコードを書き込む必要があります。
setuid/setgidを無視すると、実行ビットの1つの目的は次のとおりです。- モードでファイルを許可するにはexecute-only-execute読み取り不可のファイルへのアクセス。
質問の2番目の部分について-実装する
linux syscallについて：
新しい攻撃源を作成しているようです。
真剣な回答を得たい場合は、詳細を提供する必要があります（新しい質問で推奨）：
- どのロジックを実装しますか？
- データはどのようにRAMにコピーされますか？
- RAMでコードを実行する前に、APIはどのチェックを実行しますか？
- APIは
rootによっても実行されますか（したがって、特権エスカレーションが許可される可能性があります）