As mentioned here, there is a requirement to limit the different types of gates available.
Right now, this is done by having a directory that contains the *.class-files for the gates, and the class GateLoaderHelper that lodas classes either from that directory or from the Jar-File.
The idea here is to be able to add and remove gates without having to rebuild the Jar-File.
The ability to inject classes at the file system level, and execute their code from the simulation is a security issue: Everybody can add EvilGate.class and execute his code with the privileges of the user that runs LogicSim3.
To fix this, we need to investigate the use case, and maybe split it into two:
Removing gates from the simulation
Adding gates to the simulation
Case 1 is clearly necessary - this is what this was built for in the first place.
Is case 2 necessary? - The current state of LogicSim3 contains "all needed gates", and if somebody needs an additional gate, (s)he needs the source code and an IDE anyway.
Case 1 can be done using a (the) configuration file and have it contain a whitelist (or blacklist, or whatever is preferred) of the gates that should be available.
Gate classes would be loaded only from the Jar-File, and any Jar-File integrity measures (like signing) will also include the gate classes and thus increase security.
As mentioned here, there is a requirement to limit the different types of gates available.
Right now, this is done by having a directory that contains the *.class-files for the gates, and the class
GateLoaderHelperthat lodas classes either from that directory or from the Jar-File.The idea here is to be able to add and remove gates without having to rebuild the Jar-File.
The ability to inject classes at the file system level, and execute their code from the simulation is a security issue: Everybody can add
EvilGate.classand execute his code with the privileges of the user that runs LogicSim3.To fix this, we need to investigate the use case, and maybe split it into two:
Case 1 is clearly necessary - this is what this was built for in the first place.
Is case 2 necessary? - The current state of LogicSim3 contains "all needed gates", and if somebody needs an additional gate, (s)he needs the source code and an IDE anyway.
Case 1 can be done using a (the) configuration file and have it contain a whitelist (or blacklist, or whatever is preferred) of the gates that should be available.
Gate classes would be loaded only from the Jar-File, and any Jar-File integrity measures (like signing) will also include the gate classes and thus increase security.