Javaアプリケーションの悪意のあるコードに対するサンドボックス
ユーザーがサーバーで実行する独自のコードを送信できるシミュレーションサーバー環境では、アプレットがブラウザー内にあるのとは異なり、ユーザーが送信したコードをサンドボックスのサイドで実行することが明らかに有利です。別のVMレイヤーを追加して、送信されたこれらのコンポーネントを分離するのではなく、JVM自体を活用できるようにしたいと思いました。
この種の制限は既存のJavaサンドボックスモデルを使用して可能であるように見えますが、実行中のアプリケーションのユーザーが送信した部分に対してのみ動的にそれを有効にする方法はありますか？
信頼できないコードを独自のスレッドで実行します。これにより、たとえば無限ループなどの問題が回避され、将来のステップが容易になります。メインスレッドにスレッドの終了を待機させ、時間がかかりすぎる場合は、Thread.stopを使用してスレッドを強制終了します。 Thread.stopは非推奨ですが、信頼されていないコードはどのリソースにもアクセスできないため、強制終了しても安全です。
そのスレッドに SecurityManager を設定します。 checkPermission（Permission perm） をオーバーライドするSecurityManagerのサブクラスを作成して、一部の選択を除くすべての権限に対して SecurityException をスローするだけです。メソッドとそれらが必要とする許可のリストがあります： Javaの許可TM 6 SDK 。
カスタムClassLoaderを使用して、信頼できないコードをロードします。信頼できないコードが使用するすべてのクラスに対してクラスローダーが呼び出されるため、個々のJDKクラスへのアクセスを無効にするなどの操作を実行できます。すべきことは、許可されたJDKクラスのホワイトリストを用意することです。
信頼できないコードを別のJVMで実行したい場合があります。前の手順でコードを安全にすることができますが、分離されたコードで実行できる厄介なことが1つあります。可能な限り多くのメモリを割り当てることです。これにより、メインアプリケーションの目に見えるフットプリントが大きくなります。
JSR 121：アプリケーション分離API仕様 はこれを解決するために設計されましたが、残念ながらまだ実装されていません。
これはかなり詳細なトピックであり、ほとんどの場合、これは頭のてっぺんから書きます。
しかしとにかく、いくつかの不完全な、自分の責任で使用する、おそらくバグのある（疑似）コード：
ClassLoader
class MyClassLoader extends ClassLoader {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
if (name is white-listed JDK class) return super.loadClass(name);
return findClass(name);
}
@Override
public Class findClass(String name) {
byte[] b = loadClassData(name);
return defineClass(name, b, 0, b.length);
}
private byte[] loadClassData(String name) {
// load the untrusted class data here
}
}
SecurityManager
class MySecurityManager extends SecurityManager {
private Object secret;
public MySecurityManager(Object pass) { secret = pass; }
private void disable(Object pass) {
if (pass == secret) secret = null;
}
// ... override checkXXX method(s) here.
// Always allow them to succeed when secret==null
}
スレッド
class MyIsolatedThread extends Thread {
private Object pass = new Object();
private MyClassLoader loader = new MyClassLoader();
private MySecurityManager sm = new MySecurityManager(pass);
public void run() {
SecurityManager old = System.getSecurityManager();
System.setSecurityManager(sm);
runUntrustedCode();
sm.disable(pass);
System.setSecurityManager(old);
}
private void runUntrustedCode() {
try {
// run the custom class's main method for example:
loader.loadClass("customclassname")
.getMethod("main", String[].class)
.invoke(null, new Object[]{...});
} catch (Throwable t) {}
}
}
明らかにこのようなスキームは、あらゆる種類のセキュリティ上の懸念を引き起こします。 Javaには厳密なセキュリティフレームワークがありますが、それは簡単なことではありません。それを台無しにし、権限のないユーザーが重要なシステムコンポーネントにアクセスできるようにする可能性も見落としてはなりません。
その警告はさておき、ユーザー入力をソースコードの形式で受け取っている場合、最初に行う必要があるのは、それをJavaバイトコードにコンパイルすることです。AFIAK、これはネイティブで実行できないため、 javacへのシステムコールを作成し、ソースコードをディスク上のバイトコードにコンパイルする必要があります こちら これの開始点として使用できるチュートリアル編集：私がコメントで学んだように、実際にはソースからコードをコンパイルできますJava javax.tools.JavaCompiler =
JVMバイトコードを取得したら、 ClassLoader'sdefineClass 関数を使用してそれをJVMにロードできます。この読み込まれたクラスのセキュリティコンテキストを設定するには、 ProtectionDomain を指定する必要があります。 ProtectionDomain の最小コンストラクターには、CodeSourceと PermissionCollection の両方が必要です。 PermissionCollectionは、ここで主に使用するオブジェクトです。これを使用して、ロードされたクラスが持つ正確なアクセス許可を指定できます。これらの権限は、最終的にはJVMの AccessController によって適用されます。
ここには多くのエラーの可能性のあるポイントがあり、何かを実装する前にすべてを完全に理解するように細心の注意を払う必要があります。
Java-Sandbox は、Javaコードを制限付きで実行するためのライブラリです。これを使用して、ホワイトリストされたクラスのセットのみにアクセスを許可できます。とリソース。個々のメソッドへのアクセスを制限することはできないようです。カスタムクラスローダーとセキュリティマネージャーを備えたシステムを使用してこれを実現しています。
私はそれを使用していませんが、うまく設計されており、十分に文書化されています。
@waqasは、これを自分で実装する方法を説明する非常に興味深い回答を提供しています。しかし、そのようなセキュリティの重要で複雑なコードを専門家に任せる方がはるかに安全です。
ただし、プロジェクトは2013年以降更新されておらず、作成者はそれを「実験的」と表現していることに注意してください。ホームページは消えましたが、Source Forgeのエントリは残っています。
プロジェクトのWebサイトから変更されたサンプルコード：
SandboxService sandboxService = SandboxServiceImpl.getInstance();
// Configure context
SandboxContext context = new SandboxContext();
context.addClassForApplicationLoader(getClass().getName());
context.addClassPermission(AccessType.PERMIT, "Java.lang.System");
// Whithout this line we get a SandboxException when touching System.out
context.addClassPermission(AccessType.PERMIT, "Java.io.PrintStream");
String someValue = "Input value";
class TestEnvironment implements SandboxedEnvironment<String> {
@Override
public String execute() throws Exception {
// This is untrusted code
System.out.println(someValue);
return "Output value";
}
};
// Run code in sandbox. Pass arguments to generated constructor in TestEnvironment.
SandboxedCallResult<String> result = sandboxService.runSandboxed(TestEnvironment.class,
context, this, someValue);
System.out.println(result.get());
さて、提案や解決策を提供するのは非常に遅いですが、それでも私は同様の問題に直面していました。基本的に、私はJava e-learningプラットフォームのコースのプログラミング割り当てのプロビジョニングと自動評価を提供することを試みていました。
- 1つの方法としては、個別の仮想マシン（JVMではなく）を作成しますが、実際の仮想マシンは、学生ごとに可能な最小構成のOSを使用します。
- JavaのJRE、またはプログラミング言語に応じたライブラリのうち、生徒がこれらのマシンでコンパイルして実行するようにしたい方のライブラリをインストールします。
これはかなり複雑で多くのタスクのように聞こえますが、Oracle Virtual Boxはすでに仮想マシンを動的に作成または複製するためのJava APIを提供しています。 https://www.virtualbox.org /sdkref/index.html （なお、VMwareでも同じことを行うためのAPIを提供しています）
最小サイズと構成のLinuxディストリビューションについては、こちらを参照してください http://www.slitaz.org/en/ 、
だから今学生がそれをめちゃくちゃにしたりしようとしたりした場合、メモリやファイルシステム、ネットワーク、ソケットが原因である可能性があり、最大で自分のVMを損傷する可能性があります。
また、これらのVMの内部では、Java）のサンドボックス（セキュリティマネージャー）などの追加のセキュリティを提供したり、Linuxでユーザー固有のアカウントを作成してアクセスを制限したりできます。
お役に立てれば ！！
カスタムSecurityManagerがスレッドごとではなく、JVMのすべてのスレッドに適用されるという承認された回答の問題に対処するには、有効にすることができるカスタムSecurityManagerを作成できます次のように特定のスレッドに対して/ disabled：
import Java.security.Permission;
public class SelectiveSecurityManager extends SecurityManager {
private static final ToggleSecurityManagerPermission TOGGLE_PERMISSION = new ToggleSecurityManagerPermission();
ThreadLocal<Boolean> enabledFlag = null;
public SelectiveSecurityManager(final boolean enabledByDefault) {
enabledFlag = new ThreadLocal<Boolean>() {
@Override
protected Boolean initialValue() {
return enabledByDefault;
}
@Override
public void set(Boolean value) {
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
securityManager.checkPermission(TOGGLE_PERMISSION);
}
super.set(value);
}
};
}
@Override
public void checkPermission(Permission permission) {
if (shouldCheck(permission)) {
super.checkPermission(permission);
}
}
@Override
public void checkPermission(Permission permission, Object context) {
if (shouldCheck(permission)) {
super.checkPermission(permission, context);
}
}
private boolean shouldCheck(Permission permission) {
return isEnabled() || permission instanceof ToggleSecurityManagerPermission;
}
public void enable() {
enabledFlag.set(true);
}
public void disable() {
enabledFlag.set(false);
}
public boolean isEnabled() {
return enabledFlag.get();
}
}
ToggleSecurirtyManagerPermissionは、承認されたコードのみがセキュリティマネージャを有効/無効にできるようにするためのJava.security.Permissionの単純な実装です。次のようになります。
import Java.security.Permission;
public class ToggleSecurityManagerPermission extends Permission {
private static final long serialVersionUID = 4812713037565136922L;
private static final String NAME = "ToggleSecurityManagerPermission";
public ToggleSecurityManagerPermission() {
super(NAME);
}
@Override
public boolean implies(Permission permission) {
return this.equals(permission);
}
@Override
public boolean equals(Object obj) {
if (obj instanceof ToggleSecurityManagerPermission) {
return true;
}
return false;
}
@Override
public int hashCode() {
return NAME.hashCode();
}
@Override
public String getActions() {
return "";
}
}
この問題に対するスレッドセーフなソリューションは次のとおりです。
package de.unkrig.commons.lang.security;
import Java.security.AccessControlContext;
import Java.security.Permission;
import Java.security.Permissions;
import Java.security.ProtectionDomain;
import Java.util.Collections;
import Java.util.HashMap;
import Java.util.Map;
import Java.util.WeakHashMap;
import de.unkrig.commons.nullanalysis.Nullable;
/**
* This class establishes a security manager that confines the permissions for code executed through specific classes,
* which may be specified by class, class name and/or class loader.
* <p>
* To 'execute through a class' means that the execution stack includes the class. E.g., if a method of class {@code A}
* invokes a method of class {@code B}, which then invokes a method of class {@code C}, and all three classes were
* previously {@link #confine(Class, Permissions) confined}, then for all actions that are executed by class {@code C}
* the <i>intersection</i> of the three {@link Permissions} apply.
* <p>
* Once the permissions for a class, class name or class loader are confined, they cannot be changed; this prevents any
* attempts (e.g. of the confined class itself) to release the confinement.
* <p>
* Code example:
* <pre>
* Runnable unprivileged = new Runnable() {
* public void run() {
* System.getProperty("user.dir");
* }
* };
*
* // Run without confinement.
* unprivileged.run(); // Works fine.
*
* // Set the most strict permissions.
* Sandbox.confine(unprivileged.getClass(), new Permissions());
* unprivileged.run(); // Throws a SecurityException.
*
* // Attempt to change the permissions.
* {
* Permissions permissions = new Permissions();
* permissions.add(new AllPermission());
* Sandbox.confine(unprivileged.getClass(), permissions); // Throws a SecurityException.
* }
* unprivileged.run();
* </pre>
*/
public final
class Sandbox {
private Sandbox() {}
private static final Map<Class<?>, AccessControlContext>
CHECKED_CLASSES = Collections.synchronizedMap(new WeakHashMap<Class<?>, AccessControlContext>());
private static final Map<String, AccessControlContext>
CHECKED_CLASS_NAMES = Collections.synchronizedMap(new HashMap<String, AccessControlContext>());
private static final Map<ClassLoader, AccessControlContext>
CHECKED_CLASS_LOADERS = Collections.synchronizedMap(new WeakHashMap<ClassLoader, AccessControlContext>());
static {
// Install our custom security manager.
if (System.getSecurityManager() != null) {
throw new ExceptionInInitializerError("There's already a security manager set");
}
System.setSecurityManager(new SecurityManager() {
@Override public void
checkPermission(@Nullable Permission perm) {
assert perm != null;
for (Class<?> clasS : this.getClassContext()) {
// Check if an ACC was set for the class.
{
AccessControlContext acc = Sandbox.CHECKED_CLASSES.get(clasS);
if (acc != null) acc.checkPermission(perm);
}
// Check if an ACC was set for the class name.
{
AccessControlContext acc = Sandbox.CHECKED_CLASS_NAMES.get(clasS.getName());
if (acc != null) acc.checkPermission(perm);
}
// Check if an ACC was set for the class loader.
{
AccessControlContext acc = Sandbox.CHECKED_CLASS_LOADERS.get(clasS.getClassLoader());
if (acc != null) acc.checkPermission(perm);
}
}
}
});
}
// --------------------------
/**
* All future actions that are executed through the given {@code clasS} will be checked against the given {@code
* accessControlContext}.
*
* @throws SecurityException Permissions are already confined for the {@code clasS}
*/
public static void
confine(Class<?> clasS, AccessControlContext accessControlContext) {
if (Sandbox.CHECKED_CLASSES.containsKey(clasS)) {
throw new SecurityException("Attempt to change the access control context for '" + clasS + "'");
}
Sandbox.CHECKED_CLASSES.put(clasS, accessControlContext);
}
/**
* All future actions that are executed through the given {@code clasS} will be checked against the given {@code
* protectionDomain}.
*
* @throws SecurityException Permissions are already confined for the {@code clasS}
*/
public static void
confine(Class<?> clasS, ProtectionDomain protectionDomain) {
Sandbox.confine(
clasS,
new AccessControlContext(new ProtectionDomain[] { protectionDomain })
);
}
/**
* All future actions that are executed through the given {@code clasS} will be checked against the given {@code
* permissions}.
*
* @throws SecurityException Permissions are already confined for the {@code clasS}
*/
public static void
confine(Class<?> clasS, Permissions permissions) {
Sandbox.confine(clasS, new ProtectionDomain(null, permissions));
}
// Code for 'CHECKED_CLASS_NAMES' and 'CHECKED_CLASS_LOADERS' omitted here.
}
コメントしてください！
CU
アルノ
おそらく、カスタム SecurityManger および/または AccessController を使用する必要があります。詳細については、Sunの Java Security Architecture および other security documentation を参照してください。