Disallow student classes in trusted packages

[MaisiKoleni]

Improve security by disallowing students to create classes in the whitelisted packages in the SecurityManager by configuring a custom Proxy for the ClassLoader which will throw SecurityExceptions in such cases.

Securing the testing process will be much simpler because we can trust classes in these packages blindly at runtime. However, this will not replace the Throwable-sanitization.

[MaisiKoleni]

As a workaround, this can also be archived by telling the Maven compiler plugin to compile only classes in certain packages, like the main package of the exercise set in Artemis for example.

[MaisiKoleni]

A short overview what is possible and what not:

1. maven-compiler-plugin you can use include and exclude here, but the plugin will auto-include transitive sources that are not directly included themselves which defeats the security
2. One could delete unwanted sources with e.g. the maven-clean-plugin. While that does ensure the security, students that use other packages will get even stranger build errors reporting that classes could not be found.
3. Create a class loader that does not load classes of trusted packages from certain locations, e.g. outside of jar archives. However, enforcing the use of such a class loader dynamically only for student classes is very hard and error prone, possibly even more so than the path access and thread management. This is further complicated by the other test tool that create new class loaders on-the-fly.
4. Write an ares-maven-plugin that checks which classes have been compiled and fails the build with an intelligible error message if one violates the package restrictions.
5. Make Ares scan the class path at runtime for violations. This requires that Ares knows what classes are test classes and what are student classes.

Since 1 does not secure the build, it is not an option. 2 could be used, but would only work for maven builds, in an IDE that would have no effect. The same problem arises for 4. 3 would similar to the package restrictions of #13 only work during/before class loading and is hard to realize. For 5, I am unsure how well that could work.

In my eyes, a combination of 3 and 4 would be preferred.

Are there other options left? What would you prefer? I would be happy to hear more ideas.

[MaisiKoleni]

Currently, it is very likely it will be option 3 only.

[MaisiKoleni]

To some degree a workaround with ClassLoader.getSystemClassLoader().resources(trustedPackage.replace('.','/')) could help to find file locations that add, hide or override trusted packages. This is however difficult with all possible and different IDE and exercise testing setups.

[MaisiKoleni]

Current recommendation: use the Maven Enforcer Plugin and check that trusted packages do not exist in student code. (Should be done after compilation).