Enhancement Proposal: Ensure Principle of Least Privilege Across Subtensor Deployments

[wolfentensor]

Dear OpenTensor team,

I'm reaching out as a Coretex developer of the OpenTensor project to discuss a critical improvement in our Substrate deployment practices that I've identified and successfully tested. As part of my ongoing efforts to enhance the security posture of the OpenTensor project, a significant opportunity has been identified to align both our Docker and binary deployment methods with the Principle of Least Privilege (PoLP). This principle is a cornerstone of security and systems administration best practices, advocating for minimal user privileges to perform required tasks, thereby reducing the attack surface and potential impact of a compromise.

Currently, the service within the Docker container is configured to start and run as the root user, and similar privilege concerns apply to our binary deployment process. Furthermore, I also have not witnessed the executable performing a privdrop after initialization, suggesting that the process continues to run as root throughout its life cycle. This setup diverges from best practices by not minimizing the operational privileges of the service, potentially exposing it to unnecessary risks.

Upon further exploration and testing, I discovered that initializing and running the service as a non-privileged user within a Docker container does not adversely affect its operation, granted that the necessary file permissions have been applied before execution. This finding suggests that our service does not require root privileges for its initialization or runtime.

Implementing the Principle of Least Privilege by default in our Dockerfile could significantly mitigate potential security risks. Such risks include the escalation of privileges in the event of a vulnerability being exploited, which could lead to unauthorized access or control over the host machine or other containers.

In light of this, I propose the following changes to our Docker deployment methodology:

1. Update our Dockerfile to create and use a non-root user for initializing and running the Subtensor service.
2. Amend our documentation to reflect this change and emphasize the importance of following the Principle of Least Privilege when deploying Subtensor in all environments.
3. This enhancement will not only improve our project's security profile but also demonstrate our commitment to following best practices in software development and deployment.

I am eager to discuss this further and collaborate on implementing these changes. Your feedback and insights will be invaluable as we strive to make Subtensor safer and more resilient against potential threats.

Best Regards

[rajkaramchedu]

@wolfentensor See this for reference in context: #279

[paul-opentensor]

I agree with this. It should not be running as root, and the configuration presents privilege escalation vulnerability. Well-stated. All three of Wolf's points are valid. We should also confirm we are signing our images so they can be validated.

[paul-opentensor]

If we run into issues where application permissions are conflicting and root access is needed, user namespace mapping may be an alternative in docker.

[sam0x17]

completed in #1610