How to Prevent Malicious Scripts from Adding Controllers to My Canister?

When I deploy a canister, my principal becomes the controller. If I accidentally run a malicious script (e.g., sent in a file) that uses dfx canister update-settings --add-controller, it could add the attacker’s principal as a controller. Is there a secure way to prevent this kind of attack or isolate the deployer identity from such risks?

In Linux, there is firejail command. You could run 3rd-party scripts in FireJail.

If correctly configured (what isn’t easy), it can prevent attacks on your data.

See also script safe in my collection of scripts. But WARNING: It may not be configured for your kind of security. Therefore, I don’t warrant that it will make any 3rd-party script secure for you.

safe third-party-script.sh

I’m trying to understand the best security practice for managing permissions. Option one is to use dfx canister add-controller to add trusted principals as controllers, giving them full control (like install/upgrade), but this relies on off-chain access management. The second option is to manage roles within the canister itself: setting the deployer (ic_caller() in init) as the first admin, storing a list of admin_principals, and using #[update] methods with is_admin(caller) checks for sensitive actions. From a security and scalability perspective, which approach is better? Are there known risks with in-canister role-based access control? Does relying only on the controller model limit flexibility in multi-admin Dapps? And lastly, any best practices for implementing secure role logic in Rust?

For production canister deployment, I’d recommend a separate identity with a (long) password: dfx identity | Internet Computer

Keep in mind controllers basically have full access to the canister, if you want more fine grained access for your canister functionality you’d need to e.g. implement a role based permission system. I would not recommend making users controllers if they don’t need full access to canister.

Hi Jyotirmay,
A canister controller essentially has full access permissions (like root on Unix). One option to reduce this level of power is an SNS or a custom SNS-like system. This system would control the canisters and perform specific actions based on voting or other forms of external confirmation.