How to access GPIO via bonescript without root?

How are folks accessing the GPIO channels using bonescript without changing file ownership, permissions, or running node with sudo?

Secondly, how is beagleboard.org accessing the GPIO channels in the digitalWrite example through the web example:

http://beagleboard.org/Support/BoneScript/demo_blinkled_external/

Both the .dtbo files and gpio exports in /sys/class/gpio created by this example are owned by root! How is it possible for a web application to create a file as root on the beaglebone, in a folder owned by root? If there is not some cool sourcery working behind the scenes, I can only assume there is a massive security hole being exploited for this to work.

Why are you asking ? Do you wish to know to learn more and tighten up security on your own BBB, using one of the Demo images ? Or are you looking for ideas on how to increase security for your own images ?

The reason I ask is because I have given this a lot of thought for the last year or so myself, and have some ideas of my own. However, since file access for certain I/O will have to be as, or from root. There will always be some level of insecurity. You can do IPC between root, and a regular user, but in the end you’ll still have access to the device(s).

hosts.allow/deny could be used to some degree as well, but is also depreciated. Nodejs can run on some port 3000 or higher, and IPTables can be used to route packets from port 80 . . .etc, etc.

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).

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.

So is there a way that a node.js process could start as root, configure the hardware using bonescript functions, change to a non-privileged user ID, start a server listening on a port >3000, and still use bonescript to access the IO pins themselves? If so, how? Anyone?

Max

Max,

process segregation. You can have one Nodejs process running as root doing all the GPIO / root stuff. Another process that handles the outside communications. Then you pick a method for these two process to communicate.

what you describe though sounds very much like what I understand as setuid / setgid. However, I’m not exactly experienced with this, only have done a bit of reading on the subject.