ASM's Hook model was developed in order to support “from-boot restrictions”, i.e., in the mExam's case, ASM would require a device reboot in order for certain restrictions to effectively be enforced.
A good example of such behavior is the way ASM handles network access. ASM has hooks (via LSM) in sockets' create, connect and open operations, which means that if a device is rebooted before the exam, the restrictions can in fact ensure that no application can effectively access the network.
However, our Trust Lease model follows a different and more practical approach, in which ongoing resource usages must be stopped if required by the lease.
With this in mind, considering our decisions on how to terminate the usage of such resources, it becomes essential for us to create tests to assess if those decisions introduce unforeseen errors, i.e., new errors which apps are not currently prepared to handle.
The network was actually the first resource we dealt with, and since at that time we had little experience with the platform, we basically made things work with the little we had and knew.
Besides controlling sockets' create, connect and open operations, we restrict the rest of the socket operations (e.g., reads, writes) with the file_permission hook. Whenever there is an access to a file, we first check if that file is a socket, and in those cases we deny the access to that file, which causes the corresponding socket operation to be unsuccessful.
This approach is still used today, but we have already learned that a potentially more suitable mechanism could be taken.
Using other kernel hooks (provided by LSM) such as socket_read, socket_write could effectively prove to be equally effective, but could also bring efficiency benefits.
Adding the socket_read, socket_write and even socket_listen and socket_accept hooks remains for future work