Looks like you guys have the functionality to remotely run commands on my PiAware, presumably as root. While the list of commands isn’t a problem (and for some users it’s probably great) the possibility of this being used maliciously exists, so I will be moving my PiAware to a DMZ network.
You must be fun to work with.
Yes, this is a completely reasonable concern. I’ve got to get a better router so, I can use DD-WRT again. Then, I’ll be isolating the station. It’s an extremely high security risk with the stock PiAware configuration.
Actually, the team I am on has a lot of fun, but we’re also in networking and security, so when it comes to having my home systems open to possible exploits, I get less fun. 
Then be part of the solution and make a suggestion. The root-based configuration has already been noted as a concern and future releases are to move away from that vulnerability.
Well, if it were my system and I wanted to allow this sort of functionality, I would make a list of things that they could run, for instance:
1: Upgrade PiAware
2: Restart PiAware
3: Upgrade distribution
4: Halt system
Instead of sending the command to the Pi, the Pi could be programmed to check on a schedule (say 15 minute increments) for any pending tasks. Instead of the commands, it would get a task number, reference the task number in it’s own list and run that command. There is no way that an attacker could run malicious commands directly on the Pi, at the minimum they’d have to attack the systems thru the software repos which likely wouldn’t go unnoticed.
If someone tried to enter an invalid task number, the Pi could simply drop it since it has no reference for that number in its command list and an attacker could at most start causing issues with systems turning off or updating too often.
If there is a possibility to run a command as root on 1300+ devices, what is there to stop an attacker from taking over the whole system for a massive hack or DoS attack?
Been there, done that. If you have concerns, certainly go for it. A poster on another thread is working on an dump1090 version that avoids using root.
Q:what do paranoids die of? A: old age. In network security, the question is not, “am I paranoid”, it is “am I paranoid enough”. 
I don’t mind dump1090 running root. If someone wants to go thru the trouble to develop a mangled ADS-B packet that gives them access to my Pi, I’d buy them a beer before I wiped the Pi. My issue is with the apparent ability to send commands to my device from the FA servers and run them as root. (I don’t believe that’s a function of dump1090)
You have disabled all the network ports that dump1090 opens, then?
(More generally I agree with the OP - my piaware does not run as root - packages to follow once I’ve cleaned them up)
Outbound traffic I don’t care about. There is no inbound ports being opened thru the firewall (though there may be some if the Pi is tunneling back to FA) which would be all the more reason to isolate it.
dump1090 doesn’t initiate connections, ever. It’s all inbound connections even when the data flow is outbound.
That said, relying on your firewall (or absence of port forwarding) is reasonable if you assume all threats are external. Though I’d still rather not run as root, all things being equal.
Knowing that the FA software has the ability to run commands as root from a webpage makes me suspect that it’s a possible threat from inside, hence the need to be segmented from my internal resources.
(though we’re basically saying the same thing)
PiAware is open source and the server-side can execute a number of pre-defined commands: github.com/flightaware/piaware/ … client.tcl
Your proposal describes exactly how it works currently.
Now that I have read over it, I do see that, and I’m glad that it’s running that way. I did move my Pi to a DMZ, but it will survive there anyways.
Thanks for the clarification!