I have an application written in Go that I want to run directly on routerboard. Go produces single binary with all dependencies statically linked which does not require any system libraries. This binary worked on most mips and arm based routers without any problems and without a need for any custom toolchain for the platform.
How can I run this binary from a script or from terminal?

RouterOS is a closed platform. You can not run a 3rd party binary.

RouterOS is a closed platform. You can not run a 3rd party binary.

I am not talking about modifying RouterOS itself. I am asking how can I call my own binary which should be compatible with the platform from a script.

That's what he meant by closed, RouterOS won't allow you to run any 3rd party binary.

Allowing 3rd party binaries to run on a router/firewall is a massive security hole that could/would be used as an exploit and backdoor. I could not imagine any situation that I would ever trust a router that will run an arbitrary executable. Maybe a little linksys or something, but this isn't going to happen on any router that is intended to be secure and stable.

Running my own software has nothing to do with security. And running a binary is no different than running a script. It just gives more flexibility. By your logic ordinary server that runs custom software is insecure. And that is pretty much any server.
Besides there is already a backdoor in RouterOS. If you manage to create /nova/etc/devel-login file then a developer console will be available.

ps. Running custom software and ability to modify firmware is exactly what made linksys wrt54g the best router of that time. And it was far more secure than any other router back then.

Besides there is already a backdoor in RouterOS. If you manage to create /nova/etc/devel-login file then a developer console will be available.

Seems like you already knew the answer to your own question then.

There's no legit/"by design" way to run any binaries on RouterOS, only these type of hacks. The closest thing to a legit way is to run a MetaRouter/KVM VM, and run your binary on it instead.

The problem with this solution is that it's only easy to enable the console through metarouter. And if you have metarouter setup then it's easier and more convenient to use just that. But as far as I see metarouter only works on single core cpus. I have RB3011UiAS-RM and there is still no metarouter support for it.
I was hoping for an official and more convenient solution than this. But it seems there is none.
Anyway thanks for the answers.

Sonnix.
If you think that running any code inside router is good idea with no influence on security then please read these examples:

viewtopic.php?f=21&t=119308&hilit=vulnerability
viewtopic.php?f=2&t=120746&p=593793&hil ... ty#p593793
viewtopic.php?f=1&t=120270&p=592305&hil ... ty#p592305

Maybe that is why there is no more support for metarouters on modern devices.

Sonnix.
If you think that running any code inside router is good idea with no influence on security then please read these xamples:

viewtopic.php?f=21&t=119308&hilit=vulnerability
viewtopic.php?f=2&t=120746&p=593793&hil ... ty#p593793
viewtopic.php?f=1&t=120270&p=592305&hil ... ty#p592305

Maybe that is why there is no more support for metarouters on modern devices.

Every vulnerability you have listed exploits the code that is already running on the router and does not load anything custom beyond that what is already provided in the firmware. Limiting the ability to run your own code has nothing to do and does not prevent this types of vulnerabilities.
RouterOS is based on linux kernel. If there is a kernel exploit which works for the kernel that is loaded on the router then the limitation to run arbitrary userspace code will do absolutely nothing to stop it. If you manage to exploit the kernel then you can run the code in ring0 and override anything you want in userspace including adding files and running any code.

I think the handling of this question should have stopped at "RouterOS is a closed platform and it does not allow 3rd party binaries".
That is just the fact and there is no need to defend or explain that as "we" (in this topic) are not MikroTik and we are not defining
the product. Trying to explain it is "because of security" only starts a discussion about if allowing such binaries would affect
security, and it is irrelevant because we do not know if it is because of security and we are not the ones that can change it.

In my opinion, it is not for security but for supportability. There are other manufacturers in this market who have similarly closed
all external access and sometimes they have a switch to open it up and it displays a warning that there will be no support from
customer service after doing this. It is much harder to support a Linux-based router when there is direct access to the shell
and the kernel parameters outside the configuration interface programmed by the manufacturer.

Right, you don't need to convince us. Some of us are convinced already, give it to me anytime, even with "no support if used", no problem. Some of the others will be against it, no matter what arguments you present. But neither controls what MikroTik does. Explain to them how it would be super awesome, everyone would like RouterOS ten times more than before, and maybe they will go for it.

Hey guys, make sure you don't respond with an answer that he doesn't like. Honest and respectful answers get you rated negative by this noob.

Rereading the first mail and trying to answer once more

I have an application written in Go that I want to run directly on routerboard....
How can I run this binary from a script or from terminal?

A. It is not possible to run it inside ROS.
B. You can try to reflash Mikrotik device with your own binary like e.g. OpenWRT does it: https://wiki.commotionwireless.net/doku ... rd_devices

....In my opinion, it is not for security but for supportability...... It is much harder to support a Linux-based router when there is direct access to the shell and the kernel parameters outside the configuration interface programmed by the manufacturer.

Yes and no ....
You do need to give access to kernel level. Even user level given to the third party binary lets it to tweak e.g. user's firewall filters. How you can be sure in such situation that all your rules are respected ?
Allowing 3rd party binaries which are not verifable makes supportability only the "smaller half" of the problem.

Well, even with RouterOS as it is now, the firewall rules are 100% the responsibility of the admin.
There is nothing inside RouterOS that will protect you from doing dumb things, and no fixed firewall rules except those stupid "rules for fasttrack counting".
There are no settings like in other routers, e.g. "prevent admin from internet side" or "prevent admin from WiFi network" with a checkmark somewhere, that would generate the proper rule.
So that is not the problem.

The problem is that you would be able to set all networking parameters and do all kinds of other things, including running local services that could use a lot of CPU or disk resources, replace functionality normally provided by RouterOS (e.g. a DHCP server, an OpenVPN service), etc. Then, when there are problems, support would have to investigate your particular installation and check that all the changes you made do not contribute to the problem you report.

Pe1chl ... sorry for my poor English not allowing express properly all I want to write... I should have written:

....Even user level given to the third party binary lets it to tweak e.g. user's firewall filters behind the scenes without any visible signs of it for admin. Such "man in the middle". How you can be sure in such situation that all your rules are respected ?...

Security is really not the main problem. If RouterOS allowed to run custom binaries and you'd try anything you'd find on internet, it would of course be bad. But if it would be your own creation, you'd have security in your own hands. And even with 3rd party binaries, that's a matter of trust, common sense, etc. If you use Windows, you run 3rd party binaries all the time and with rare exceptions it works great.

The great thing is that you are free to choose what to use for a router: a Windows box, a Linux box, a FreeBSD box, a closed box with Linux inside (like MikroTik), a closed box with its own OS (like Draytek or Cisco), a half-open box with an OS inside with access to it (like Juniper).
So it is easy to buy something which does what you need. When you need to run custom binaries, that isn't MikroTik.

Finally, when you have bought the wrong box you might be able to save your investment by installing other firmware on it.

Another point to be made. We already receive a lot of support requests from beginners that somehow have a MikroTik device in their system, and nobody maintains it. We can usually help to some degree, since the software is all the same. But when there are unknowns, like custom packages, there is no more telling what is causing a problem.