他のアプリケーションと同様に、Emacsはオペレーティングシステムがアクセス権限などのルールを強制するセキュアな環境で実行可能です。適切に配慮すれば、Emacsベースのアプリケーションも、こうしたルールをチェックするセキュリティペリメータの一部として組み込むことができます。Emacsのデフォルト設定は一般的なソフトウェア開発環境では十分に機能しますが、攻撃者を含む可能性のある信頼できないユーザーが存在する環境では、調整が必要になる場合があります。以下に、こうしたアプリケーションを開発する際に役立つセキュリティ上の問題点をまとめました。これは決して網羅的なリストではなく、セキュリティチェックリストとしてではなく、どのようなセキュリティ上の問題が関わるかの目安を提供することを目的としています。
Emacsが参照するファイルには、そのファイルを参照するバッファに影響を与える可変設定を含めることができます。詳細はファイルローカル変数を参照してください。同様に、ディレクトリでは、そのディレクトリ内のすべてのファイルに共通するローカル変数の値を指定できます。詳細はディレクトリローカル変数を参照してください。Emacsはこれらの変数の誤用を防ぐための対策を講じていますが、パッケージがsafe-local-variableを過度に寛容に設定しただけでセキュリティホールが生じることがあり、こうした問題は非常に頻繁に発生します。ファイルとディレクトリの両方でこの機能を無効にするには、enable-local-variablesをnilに設定してください。
Emacsは通常、基盤となるオペレーティングシステムのアクセス権限に従いますが、場合によってはアクセスを特別に処理することがあります。例えば、ファイル名にハンドラを設定することで、独自のアクセスチェックを用いてファイルを特別に扱うことができます。特定のファイル名を「マジック」にするを参照してください。また、対応するファイルが書き込み可能であってもバッファが読み取り専用になったり、その逆となったりすることがあり、その結果、‘File passwd is write-protected; try to save anyway? (yes or no)’のようなメッセージが表示されることがあります。読み取り専用バッファを参照してください。
Emacsには、read-passwdなど、パスワードを扱う関数がいくつか用意されています。パスワードの読み取りを参照してください。これらの関数はパスワードを外部に漏洩させようとするものではありませんが、その実装は、Emacsの内部構造にアクセスできる執念深い攻撃者に対して万全とは言えません。例えば、Elispコードでclear-stringを使用して使用後のパスワードをメモリから消去したとしても、パスワードの残骸がガベージコレクション済みのフリーリストに残っている可能性があります。文字列の変更を参照してください。
Emacsは他の多くのアプリケーションにコマンドを送信できますが、アプリケーション側では、これらのコマンドのオペランドとして送信される文字列がディレクティブとして誤解釈されないよう注意する必要があります。例えば、シェルコマンドを使用してファイル名
a を b にリネームする場合、単に文字列 mv a b
を使用してはいけません。なぜなら、どちらのファイル名も ‘-’
で始まる可能性があったり、‘;’
のようにシェルのメタ文字を含んでいたりする場合があるからです。shell-quote-argument
のような関数を使えばこうした問題を回避できますが、万能ではありません。例えば、POSIXプラットフォームでは shell-quote-argument はシェルのメタ文字をクォートしますが、先頭の ‘-’ はクォートしません。MS-Windowsでは、‘%’ をクォートする場合、環境変数のいずれの名前にも ‘^’ が含まれていないことが前提となります。シェル引数を参照してください。通常、サブシェルを使用するよりも call-process を使用する方が安全です。同期プロセスの作成を参照してください。さらに、Emacsの組み込み関数を使用する方がより安全です。例えば、mv を呼び出す代わりに (rename-file
"a" "b"
t) を使用してください。ファイル名と属性の変更を参照してください。
Emacsは、アクセスするファイルやネットワーク接続のコーディングシステムを推論しようとします。コーディングシステムを参照してください。Emacsの推論が誤っていたり、ネットワーク接続の相手方がEmacsの推論に同意しなかったりした場合、結果として得られるシステムは信頼性に欠ける可能性があります。また、正しく推論できた場合でも、Emacsは他のプログラムでは利用できないバイトを使用できることがよくあります。例えば、Emacsにとってヌルバイトは他の文字と同様の単なる文字に過ぎませんが、多くの他のアプリケーションはこれを文字列終端文字として扱い、ヌルバイトを含む文字列やファイルの処理を誤ることがあります。
POSIXでは、Emacsの動作に影響を及ぼし得る環境変数がいくつか規定されています。名称がすべて大文字のASCII文字、数字、およびアンダースコアで構成される環境変数は、Emacsの内部動作に影響を与える可能性があります。Emacsでは、例えばEMACSLOADPATHなど、こうした変数をいくつか使用しています。ライブラリ検索を参照してください。プラットフォームによっては、Emacsが呼び出す可能性のあるあらゆるユーティリティで標準的な動作を実現するために、一部の環境変数（例：PATH、POSIXLY_CORRECT、SHELL、TMPDIR）に適切に設定された値が必要です。TZのような一見無害に見える変数であっても、セキュリティ上の影響を及ぼす可能性があります。オペレーティングシステム環境を参照してください。
Emacsには、同様の考慮事項を伴うカスタマイズやその他の変数があります。例えば、変数 shell-file-name
が非標準的な動作をするシェルを指定している場合、Emacsベースのアプリケーションが正常に動作しない可能性があります。
Emacsをインストールした際、インストール先のディレクトリ階層が信頼できないユーザーによって変更できてしまう場合、そのアプリケーションを信頼することはできません。これは、Emacsが使用するプログラムや、Emacsが読み書きするファイルのディレクトリ階層についても同様です。
Emacsは頻繁にネットワークにアクセスするため、通常行われるネットワークアクセスを回避するように設定したい場合があります。例えば、tramp-mode を nil
に設定しない限り、特定の構文を用いたファイル名はネットワークファイルとして解釈され、ネットワーク経由で取得されます。The Tramp Manual の The
Tramp Manual を参照してください。
Emacsアプリケーションにも、他のアプリケーションと同様の競合状態の問題が発生します。例えば、(file-readable-p "foo.txt") が t を返したとしても、file-readable-p
の呼び出しから現在までの間に別のプログラムがファイルの権限を変更したため、foo.txt
が読み取り不能になっている可能性があります。アクセシビリティのテストを参照してください。
Emacsがメモリやその他のオペレーティングシステムのリソースを使い果たすと、通常は正常に完了する計算がトップレベルまで戻って中断されるなど、動作の信頼性が低下することがあります。これにより、Emacsが通常であれば実行していたはずの操作を行わなくなる可能性があります。