Never allow a Nodejs process that faces the internet to run as root. *EVER*. That's #1 rule. Think of these Demo images as probably not setup for the best security "enabled", but as something to demonstrate some basic features of the hardware. Very easily. They're not really meant to face the internet as is, without tweaking.
So here's an idea, that could be thought of as very simple IPC, all doable 100% from Nodejs. 1) Nodejs process running as root acting as a "getter/setter" type application. This app has no connectivity to the outside world what-so-ever. This process also watches a single file for changes. This process makes changes to the I/O on the board, based on variables in this file. As such you can limit what is actually exposed to the "internet" through this intermediate file. 2) A Nodejs process that faces the internet and is run as a regular user that has limited permissions. This user also owns the file that the getter/setter app bases its changes on( this file could even be based in memory only ). This process also works using a port 3000 or higher to avoid *having* to be root for this reason alone. root then runs iptables to route all traffic on port 80 to this port. Problems: The normal user based process( web app, or whatever ) is still facing the internet. So anything you can change, someone else who can gain access to this network can make the same changes. Potential added complexity, and / or potential for "unknown" exploits. Mitigation: The beaglebone could be behind a firewall with very strict access policies. Or for data only ( only getter access to the root process ), the 2nd process could be on a different system entirely. You could setup a VPN, or create a tunnel through the firewall . . . Can think of 500 different things you could do to minimize security issues. But as long as anything has access to the internet, security problems are always going to be a potential threat. On Sun, Aug 10, 2014 at 3:41 PM, Mike Erdahl <[email protected]> wrote: > Actually security is not a huge concern at this point (will be looking at > security frameworks like passport.js shortly). At this stage I'm just > writing a application that controls GPIO on the BBB based on JSON data that > will eventually come from a cloud service. I am interested in the > mechanism beagleboard.org uses to communicate to the BBB to create the > necessary device tree overlays and /sys/class/gpio files from user space so > I can do the same on my system. I have done some quick searching and it > seems the common answer is to run as root, change permissions/ ownership, > but I'd prefer to avoid that route if possible (and there clearly is a > solution that exists in the case of bb.org). > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
