Description
Currently, there doesn't appear to be any way to completely disable the loading of plugins. Individual plugins can be disabled, but there is no way to force micro to only run its own self-contained code.
Since plugins are loaded from the user-writeable ~/.config/micro folder, any process which can write into that folder could inject a plugin. This could be a concern in security sensitive contexts. Preventing this would be a significant attack surface reduction.
I am aware this would likely mean disabling the builtin extensions as well. I am fine with this.
Edit: Of course, this would need to be configurable somewhere that's not user-writeable, for obvious reasons... perhaps a separate config file in /etc/micro would be best. Would be good for other security related options like autosu, and would allow global configuration in multi-user setups as well.
Activity
2
Commenter253mo agoMy thoughts are more around privilege escalation attacks. For example, if you set micro to be used by sudoedit, I'd think a process capable of writing to the config directory could take advantage of this to modify a normally inaccessible file.
Admittedly this is more of a hypothetical my 4am brain came up with. Someone misinterpreted something I said and thought I was saying micro is more secure than GNU nano, which wasn't what I meant, but that made me wonder about micro's security in general... and taking a cursory 4am glance, the plugin system is the only thing I really saw and immediately felt like could be concerning.
Regardless, I can't imagine it would cause harm to disable it. If it's not in use, why leave the door open? I imagine it could have performance benefits too, especially since it seems like there'd be no need to load anything Lua related.
You can point micro to a directory that is not user-writeable with
micro -config-dir $SAFE_DIRECTORY.It does not seem like a legitimate attack surface though. If the attacker is able to write arbitrary content to arbitrary location you're already pwned.