JavaのSecurityManagerを非推奨とするJEP-411の導入を受けて、この変更による影響と予想される結果、およびJava 17(長期サポート(LTS)リリース)の早期リリースビルドでの実装に関する議論に、いくつかのプロジェクトが意見を述べている。特に、Oracleの発表した技術論文"Security and Sandboxing Post SecurityManager"に対して、Apache NetBeansは、同プロジェクトがSecurityManagerを使用しているために、JDK17-EAでの開発に着手できていない点を訴えている。
LoomのプロジェクトリーダであるRon Pressler氏による前述の論文には、Security Managerの廃止を正当化するための状況説明が記されている。
- SecurtyManagerクラスは元々、信頼できないコードがもたらす脅威に対する防御を目的として設計されたものだ ... 一般的にサーバは、信頼できるコードを主体として運用される傾向にある ... そして、サーバが直面する脅威は、周到に操作された入力によって、信頼されたコードが意図しない動作を行うという、脆弱性のエクスプロイトが中心なのだ。
- Security Managerはほとんど使用されていない。
- メンテナンスに要するコストに対して、得られるメリットが見合わなくなっている。
論文では、呼び出しコードのコンテキストに基いて機密性の高い操作の許可あるいは禁止を行う、シャロー/ディープサンドボックスに関する一連のソリューションを提唱した上で、その一例として、信頼されていないライブラリなどのコード内の特定のモジュールによる、Java.lang.Runtime内の関数のような機密性の高いコードの呼び出しを禁止する方法について紹介している。
Javaアプリケーションに対する一般的脅威
いくつかのセキュリティ関連組織やソフトウエア開発コミュニティが、多数のアプリケーションに影響する脅威のタイプに関する追跡を行っている。OWASPの運営するOWASP Top 10、SANSが管理するSANS Top 25などの他、VerisonはVerizon Data Breach Incident Report(DBIR)を年次で公開している。
2020年のDBIRは、約29,000件のセキュリティ侵害に基づいて、Webアプリケーションに対して頻度の高まっている攻撃パターンを紹介している。これらのシナリオの攻撃パターンは、Pressler氏がSecurityManagerの記事で取り上げた"周到に操作された入力"の定義とも一致する。DBIRの付記では、Javaデシリアライゼーションの欠陥(OWASP A8)を利用した、Oracle WeblogicのMayインシデント攻撃(CVE-2020-2883)が特に取り上げられている。デシリアライゼーションの欠陥は、信頼されたWebアクセス可能なライブラリをysoserialのようなガジェットによる悪意ある入力で攻撃するという、一般的なクラスのアプリケーション攻撃である。WeblogicがSecurityManagerを使用したガイダンスを公開していたにも関わらず、このエクスプロイトは侵害に成功している。
OpenJDKはシリアライゼーションの防御策を提供しているが、SecurityManagerではなくシリアライゼーションフィルタ機構を使用する。
SecurityManagerの使用法
JavaコミュニティにおけるAPIや機能レベルの使用統計は公開されていないが、システム強化のガイドがさまざまな標準や著名な出版物によって提供されている。多くが同じような推奨事項を提供する一方で、SecurityManagerについては言及していない。
- Java 8のDISA STIG(Secure Technology Implementation Guide)には16の項目が挙げられているが、SecurityManagerには言及せず、その使用もオプションになっている。STIGは米国防省では必須項目である。
- Javaインメモリデータグリッド大手が公開している、運用ガイドとセキュリティ機能に関する100ページ超の資料では、SecurityManagerについては使用、推奨、あるいは言及することなく、ポリシのコンフィギュレーションファイルの提供や必要な権限を提示している。
- AppDynamicsはSecurityManager用のガイダンスを提供しているが、サンプルのポリシファイルでは最小権限の原則は適用せず、java.security.AllPermissionを付与している。
- Datastaxが提供する"Securing Cassandra"というJava NoSQLデータベースのガイドでは、SecurityManagerには言及せず、ポリシファイルも提供しない。
- ParayaとSynkの共著である"How to Develop Applications with Minimal Security Risks"という10ページのJava開発者向けガイドでも、SecurityManagerには言及していない。Synkによるこれとは別の実践ガイドはSecuriyManagerを推奨しているものの、著者のひとりは"エンタープライズ開発でSMを使ったことは一度もない"という矛盾した発言をしている。
- JBossもWebLogicと同様、SecurityManagerの利用ガイドを提供している。
SecurityManagerの使用の有無は、プロダクトや企業のセキュリティ上の不備とは結び付いていない。
Apache、NetBeans、Solr、RIver、ElasticSearch、Eclipseへの影響
JEPプロセス期間中には、いくつかのプロジェクトから、非推奨化や今後の扱いに対する懸念の声が上がっていた。Apache NetBeansはブログで、同アプリケーションがJDK 17-EAでは起動すらできない点を憂慮している。この記事は、同IDE(統合開発環境)が補償的なコントロールではなく、IDE内で運用するプラグインのAPI利用を検出する手段として利用いていることを論じた、前回のブログに続くものだNetBeansが影響を受けるのは、今回Java 12のシステムプロパティが変更された結果として、コマンドラインから機能フラグを有効にしなければならない点だ。この機能フラグの変更は、事前告知されていた非推奨化の手順とは違って、forRemovalブール型でマークされるよりも早く、非推奨の通知と同時に実施されている。
これに関する論点のひとつは、約20年にわたって使用された動作の変更に対して、30日というレビュー期間は短すぎるのではないか、というものだ。
Eclipseはこの機能フラグによる影響について、予想される変更に関するチケットで論じている。
OpenJDKのメンテナたちは、プロパティを元の値に戻すことで、ダウンストリームのプロジェクトに対して、LTSリリースであるJDK 17の有効期間内に調整を行うための十分な対応時間を提供している。
Apache RiverプロジェクトのPeter Firmstone氏は、"最小権限の原則、およびJEP 411がJavaSecurityに与える悪影響"についての記事をFoojayに投稿した。この記事では、同プロジェクト以外の多くの開発者がSecurityManagerを使用していない事実を認める一方で、ポリシファイルの生成を容易にするユーティリティが提供されている点を指摘している。
JEPプロセスの次のステップ
JEP-411にはこの後、コミュニティ全体でメンテナンスと支援を共有するための共同作業期間としての数か月が残っている。今後のステップとしては、JEP(Java Enhancement Proposal)からJSR(Java Spec Review)への移行の後、Java Community Process Executive Committeeによる最終的な投票が行われる。