Constrain rights of post-install script?

[pledbrook]

The post-install script is a dangerous beast, which could wreak havoc on a user's system. We can rely for a time on verifying the safety of various templates before including them in the main repository, but if the number of templates increases significantly, we just can't keep that up.

The post-install script should really run in a limited sandbox by default unless the user explicitly authorises the script to run with unlimited permissions. Ideally the script would have full filesystem access to the project directory, but nowhere else. Perhaps global read permissions would be OK, but even that might be too much.

Anyway, it's clear this issue needs to be researched and a general security policy decided upon before it's implemented.

[tbarker9]

I would recommend three levels of protection:

1. Only can unpack files
2. Can filter files
3. Can do anything

2 and 3 would require Y/N input from user. Do a search on the script for processTemplate to handle 2, use SecureASTCustomizer somehow for 3 (maybe even 2?). I admit ignorance in this area, so maybe there is a better way.

[tbarker9]

Or maybe:

1. Only script methods supported, excluding processTemplates (possible to inject scary code in templates)
2. processTemplates
3. Everything

[pledbrook]

I think we need to use a security policy as describe in this blog post. To my mind, the key things to restrict are:

• network calls, either running a server socket or connecting as a client;
• file system access outside the directory in which the template is unpacked;
• execution of external processes (covered by execute FilePermission);
• System.exit(); and
• potentially setting system properties, although I don't see this as a major problem.

I'm not sure that SecureASTCustomizer, as described in Cédric's blog post, really does enough for us to be worthwhile, since we need to hook into the security manager anyway.

[tbarker9]

Maybe "some system call".execute() too?

On Mon, Aug 12, 2013 at 4:50 PM, Peter Ledbrook [email protected]:

I think we need to use a security policy as describe in this blog posthttp://www.chrismoos.com/2010/03/24/groovy-scripts-and-jvm-security. To my mind, the key things to restrict are:

• network calls, either running a server socket or connecting as a client;
• file system access outside the directory in which the template is unpacked;
• System.exit(); and
• potentially setting system properties, although I don't see this as a major problem.

I'm not sure that SecureASTCustomizer, as described in Cédric's blog posthttp://www.jroller.com/melix/entry/customizing_groovy_compilation_process, really does enough for us to be worthwhile, since we need to hook into the security manager anyway.

— Reply to this email directly or view it on GitHubhttps://github.com/pledbrook/lazybones/issues/60#issuecomment-22524329 .

[pledbrook]

Good catch. Yes, scripts shouldn't be able to execute external processes by default.

Also, this online book on JAAS will prove useful as we will probably have to change policy on the fly. Which isn't easy with the Java security model.

[pledbrook]

Cédric has posted an alternative solution for sandboxing Groovy scripts that could prove useful and simpler than using the security manager. It does work on the basis of compile-time type checking, so it only protects against known properties and methods.