In the current form (from what I understand anyway) is that the root CA could be used to MITM HTTPS and other TLS connections that use the system certificate store (e.g. Google Chrome, iOS Safari) transparently if the box were to get popped (or your friend isn't one).

If the root were technically constrained there'd be less of a possibility to do damage to stacks that support the constraints if the private key were obtained.

Here's a selection of the constraints that could possibly be used but I'm sure I've missed or used some incorrectly:

• Basic Constraints, pathlen:0 - This prevents a subordinate/intermediate CA from being created under the root CA
• Name Constraints: This could be used to only allow issuance to the IP address of the server (permit: IP:<server>) This would probably affect client certificate issuance too but a randomly generated reserved "DNS name" might work for the permit side such as DNS:<uuid4> allowing <client name>.<uuid4> to be valid
• Extended Key Usage: serverAuth, clientAuth, OCSPSigning(?)