Discussion :

[SpongeBobSQP]

Bonsoir à tous,

Je cherche depuis plus d'un mois -sans succès- à me servir du SecurityManager de Java pour "sandboxer" des plugins (threadés) lancé depuis une application principale sur laquelle je ne veux pas de SecurityManager (seulement sur les plugins)

Actuellement voilà mon schéma:

PluginSecurityManager.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
public class PluginSecurityManager extends SecurityManager {
	private boolean restricted;
 
	@Override
	public void checkPermission(Permission perm) {
		check(perm);
	} 
 
	@Override
	public void checkPermission(Permission perm, Object context) {
		check(perm);
	}
 
	private void check(Permission perm) {
		if (!restricted) 
			return;
 
		throw new SecurityException("Permission denied");
	}
 
	public void enableSandbox() {
		restricted = true;
	}
 
	public void disableSandbox() {
		restricted = false;
	}
}

Plugin.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public abstract class Plugin implements Runnable {
 
	public void run() {
		SecurityManager old = System.getSecurityManager();
		PluginSecurityManager psm = new PluginSecurityManager();
		System.setSecurityManager(psm);
		psm.enableSandbox();
 
                pluginMain();
 
		psm.disableSandbox();
		System.setSecurityManager(old);
	}
 
}

SubPlugin.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public abstract class SubPlugin extends Plugin {
	public int startPlugin() {
		super.run();
		return 0;
	}
}

PotentiallyHarmfulPlugin.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class PotentiallyHarmfulPlugin extends SubPlugin {
	public void pluginMain()
	{
            // Do something nasty here !
	}
}

(L'héritage Plugin/SubPlugin vient des contraintes de mon projet et n'est à priori pas lié au problème)

Le souci avec ce schéma là qui me parait le plus "proche" techniquement de ce que je veux faire (j'ai testé plein de maniéres différentes, sans plus de succés), c'est que le SecurityManager n'est pas "restreint" au thread, et interdit donc par la suite tout appel de fonction dans le programme principale. Ce qui se constate par le fait également que quand je lance plusieurs plugins, après le premier, pour les autres le SecurityManager indique ne pas avoir d'accès aux permissions suivantes:

("java.lang.RuntimePermission" "createSecurityManager")
("java.lang.RuntimePermission" "setSecurityManager")
("java.lang.RuntimePermission" "getProtectionDomain")

ce qui parait "logique" dans le sens ou je veux pas qu'on puisse changer de SecurityManager depuis un plugin (même si de toute façon actuellement, *rien* n'est autorisé depuis les plugins, voir code ci-dessus), mais me montre bien qu'il essaye de réactiver un SecurityManager alors que l'autre n'est pas desactivé. (donc en gros, ça marche pô.)

Suis-je loin de ce que je voudrais faire, est il possible de restreindre l'activation du SecurityManager à des threads spécifiques ?

En vous remerciant par avance,

[adiGuba]

Salut,


Tes plugins sont toujours lancé dans des threads ?
Dans ce cas il suffit de leur associé un ThreadGroup spécifique, et de vérifier cela dans le SecurityManager.

Du coup tu peux le laisser tout le temps activé sans problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class PluginSecurityManager extends SecurityManager {
	private final ThreadGroup restrictedGroup;
 
	public PluginSecurityManager(ThreadGroup restrictedGroup) {
		this.restrictedGroup = restrictedGroup;
	}
 
 
	@Override
	public void checkPermission(Permission perm) {
		checkPermission(perm, null);
	} 
 
	@Override
	public void checkPermission(Permission perm, Object context) {
		if (Thread.currentThread().getThreadGroup()==restrictedGroup) {
			throw new SecurityException("perm="+perm);
		}
	}
}

Bien sûr il ne faut pas oublier ensuite créer les Thread avec ce ThreadGroup...



a++

[tchize_]

Tu notera que les plugin ne pourront vraiment rien faire:

Pas d'introspection (soit c'est normal)
Pas d'accès réseau / fichier (là, c'est encore normal)
Pas de création de thread (ça risque d'être plus embêtant), donc pas d'accès à Swing (pas d'interface graphique possible)
Etc...

En gros tes plugins seront limités à ne faire que du calcul.

Est-ce qu'un architecture type OSGi ne serait pas plus indiquée, il me semble qu'elle peux justement déjà gérer proprement les droits par plugin.

[SpongeBobSQP]

Salut,
Dans ce cas il suffit de leur associé un ThreadGroup spécifique, et de vérifier cela dans le SecurityManager.

Solution parfaitement adapté à mon cas, d'autant que, du coup, on peut créer plusieurs "niveaux de privilége" en fonction du ThreadGroup des plugins. Merci !

J'en profite pour poser une question liée, y'a t'il un moyen pour remplacer le print de la stacktrace pas très "esthétique" en cas de fonction non autorisé ? Si on catch l'exception que l'on vient de throw, en plus d'être parfaitement immonde niveau code, cela ne fonctionne pas puisque la fonction est alors consideré comme faisant son return; sans soucis.

En gros tes plugins seront limités à ne faire que du calcul.

Ca tombe bien, c'est exactement ce que je veux qu'ils fassent
Plus sérieusement, je préfere une approche "opt-in" dans le cadre mon projet, d'ou ce choix.

Est-ce qu'un architecture type OSGi ne serait pas plus indiquée, il me semble qu'elle peux justement déjà gérer proprement les droits par plugin.

Pourrait tu m'en dire plus là dessus ? je ne connaissais pas OSGi, et la page de Wikipedia me décrivent un framework Java qui me parait assez éloigné de mes besoins immédiats. Qu'en est il ?

[tchize_]

Pourrait tu m'en dire plus là dessus ? je ne connaissais pas OSGi, et la page de Wikipedia me décrivent un framework Java qui me parait assez éloigné de mes besoins immédiats. Qu'en est il ?

C'est évidement une assez grosse artillerie, ça permet de développer ton application en modules, chaque module étant isolé. Du coup ça gère déjà la sécurité par module, l'isolation des classloaders, le déchargement, le rechargement, etc. A voir si t'as d'autres besoins qui seraient couvert. Parce que coder soit même un SecurityManager... On arrive vite à faire une bourde


Par exemple, est-ce que ton securityManager autorise un appel à SwingUtilities.invokeLater(....)? Si oui, tu as autorisé tes plugins à exécuter un code en tant que swing, donc en dehors du threadgroup....


Avec l'arrivée de java 8, on va pouvoir paralléliser les collections. C'est faire à partir d'un threadpool central, donc encore une fois en dehors de ton ThreadGroup. Du coup je pourrais glisser du code malveillant dans la fonction parallélisée et hop.... je suis sortis de tes contraintes.

Pour moi se baser uniquement sur le thread... C'est utopique