Limit commands to Linux (ar9331) from Yun (32u4)

Official Hardware Classic Yún
1

Hi,

I'm a newbie with Yùn, but i'm a programmer-analyst and i have good experience also in linux administration. I have a project to automate a few physical things and i think that i could use Yùn and other arduinos to accomplish this. The bridge library looks great but from a security standpoint, i have some questions. Is there a way to control (or limit) the commands that the 32u4 microcontroller can run on the ar9331 Linux side? I have tried to find answers to this without any success.

The reason for this is pretty simple. If i develop an application to control everything on the Linux side, i do not want somebody hacking it via the 32u4 side. From what i can see, the bridge library allows the 32u4 side to run any commands it wants on the linux side. If there is no way to control those commands, then this would be a serious security issue if i was to build something for production.

Thanks.

Regards.

2

The 32u4 consoles ar9331 Linux side means physical access. An attacker with physical access to the console, or worse yet the hardware itself has many potential avenues of attack they can pursue. Worse yet if their goal is to simply deny use of service, or damage the software and hardware doing so is trivial (drop it into water). The attacker is only required kindergarten educated.

3

Thank you sonnyyu for your answer.

I can think of many ways to physically damaging the equipment. This portion i can live with.

What i'm addressing is more of a data integrity problem. If i build a product to sell to customers, with an application on the Linux side that has sensitive information, i want linux to be as bullet proof as possible. There is a firewall on it with much security, and that is fine, but if someone gets to the hardware with a simple USB cable, then there is a huge hole saying please hack me. Linux should be in control here, and anything else wanting access should at least be controlled in some way by Linux OS. The data sensitive applications want to make sure the OS is in control of anything accessing it. In Unix like environments we have sudo that can control commands we want to run as other users. Is there, or will there be, a mechanism such as this on Yun?

4

Or the console should at least be password protected and only allow predefined commands without the use of a password.

5

Would it assist your problem if the Linux side was in charge of the Arduino side rather than vice-versa.

This is illustrated in this Thread - although the example was not written with security in mind.

...R

6

PapaRazzzzee:
Or the console should at least be password protected and only allow predefined commands without the use of a password.

@PapaRazzzzee,
what you are asking for is possible.

I've been documenting the Yun for some time, and the links to some of my Notes have been publish in this forum. However, you can get to them directly from here:

Documenting the Yún
http://codesnippets.altervista.org/documentation/yun/index.html

The notes that Robin2 pointed you to is just one strategy, but it is a very good start. You'll see his tutorial listed under Projects & Software

In short, there is a tty (terminal) between the Atmega and Linux. It is an open port, but you can modify it's access. Robin2's documentation points to the right place to insert your change. Namely, you want to change /etc/inittab.

After that you'll find more documentation at OpenWrt. Now you might have trouble finding stuff as they have just started reorganizing the documentation side of the website. However, you can go to the documentation section of the forum (https://forum.openwrt.org/) and they will help you find things. FYI: I'm part of team, but I have not kept up in the last 3 weeks.

In addition, you can apply SSH as the login shell and apply the usual SSH rules. But be aware, there might limitation - as OpenWrt and YunOS use similar policies -- that root is the default login.

If you have more questions, there will be more people with more experience on tomorrow.

OH. One note, SonnyYu's english is limited, but his technical skill are superior and his knowledge is excellent. I think your project has him excited.

Jesse

7

jessemonroy650:
The notes that Robin2 pointed you to is just one strategy, but it is a very good start. You'll see his tutorial listed under Projects & Software

Thank you Jesse.

I had not realized that is what you were doing.

...R

8

Hi Robin and thank you for your answer.

I have studied your code and i like the principle. This patches a big portion of the hole. Unfortunately, i don't beleive it patches it completely because the way i see it, when Linux opens the connection it still allows Yun to do whatever it wants for the time the connection is opened. But it's way better than where we started for sure.

I'll take a look at Jesse's suggestions now.

Thanks a lot guys for your help on this, it's very appreciated.

9

Because of the hardwired serial connection between the 32U4 and the AR3391, the Yun has some inherent security risks. On the Linux side, you can edit inittab to disable the Linux CLI on the serial port. You will then need to write some Linux side code to process commands, and that code can implement your security policy by only handling those commands that you choose. This is the gist of Robin2's approach, although I don't believe he is doing it that way for security reasons.

While that will increase your security, it will not be sufficient for your goals. While booting, that serial port is still used for the uboot output, and the pre-init output, both of which allow you to type any key to interrupt the boot sequence and take control of the AR9331 processor. Editing inittab will not prevent this from happening.

I hate to say it, but if you are making a commercial product, and you need a high level of security from an attack vector through the 32U4, I don't think the Yun will be a good fit.

10

PapaRazzzzee:
when Linux opens the connection it still allows Yun to do whatever it wants for the time the connection is opened.

Don't you have complete control over the code that is on the Arduino so I don't see how it could do anything malicious?

Route ALL the comms through Linux and just use the Arduino for I/O - the stuff the Atmega is good at.

...R

11

If someone gets physical access to the Yun, to get to the AVR side and replace the currently running sketch with a custom one that allows that person to execute arbitrary code via the bridge on the shell of the Linux side of that Yun, then there is nothing that this person prevents from accessing and overwriting the Linux side as well.

If the sketch on the AVR side is being replaced (remember that you do not have a "dynamic" environment here!), this is rendering whatever you do on your Yun useless, no matter how hard you are trying to lock down the Linux side.

If someone goes to the length that is necessary to accomplish the above, you have a lot more things to worry about...

Ralf

12

Physical access plays a big role in IT infrastructure security. I have worked in huge infrastructures, i know what i'm talking about. But physical access to a box is not the only physical security there is. The box itself needs a minimun security. Let's say i work as an operator in a server room, and if i want to hack a server i need to open the case, either by having the key of the case or by breaking it with a hammer. In both those methods i'm going to draw attention of my fellow workers because it's either going to take me some time to do it or i will make a lot of noise. That's the bare minimum physical security an IT device needs to have. Just plugging a USB cable and uploading a sketch does not cut it for minimum physical security.

Conclusion, i beleive ShapeShifter is right. The Yùn can only be considered as a toy and in no way can it be seriously considered for commercial production, at least not in its present form.

13

PapaRazzzzee:
::::SNIP::::

Conclusion, i beleive ShapeShifter is right. The Yùn can only be considered as a toy and in no way can it be seriously considered for commercial production, at least not in its present form.

I disagree. However, the amount of work to make it be secure to a reasonable extent may require more effort than starting from scratch.

I think, if you are using the Yun as a prototype, and your install base is reasonable low (say 25-100 units) then you are okay. But, of course, painting a target on oneself is not helpful... like a big sign saying, "Automated Facebook Login, Do not touch."

Jesse

14

PapaRazzzzee:
Or the console should at least be password protected and only allow predefined commands without the use of a password.

Make console with password:

nano /etc/inittab

change

ttyATH0::askfirst:/bin/ash --login

to

ttyATH0::askfirst:/bin/login

Since Yun firmware has login disable, we have to re-enable it and re-compile firmware.

15

PapaRazzzzee:
...
Linux should be in control here, and anything else wanting access should at least be controlled in some way by Linux OS. The data sensitive applications want to make sure the OS is in control of anything accessing it. In Unix like environments we have sudo that can control commands we want to run as other users. Is there, or will there be, a mechanism such as this on Yun?

Demote from root:

http://forum.arduino.cc/index.php?topic=284982.msg1997130#msg1997130

16

Most efficient way to erase data and destroy Yun.

full power and 10 second.

17

PapaRazzzzee:
Physical access ....
Conclusion, ... in no way can it be seriously considered for commercial production,

I can think of mechanical-type reasons why you might not use a Yun in a production system but I think your comment is specifically related to security issues.

You may have come to this conclusion beased on information that you have not shared with us but I don't see any evidence for it in your posts here.

Effective security solutions must be based on a proper risk analysis. As you have not told us what threat you are trying to prevent it is a bit difficult to make anything except general comments.

I still fail to see how the Arduino side of a Yun can present a security risk if you design your system properly - and that was the basis of your original enquiry.

...R

18

sonnyyu:
change

ttyATH0::askfirst:/bin/ash --login

to

ttyATH0::askfirst:/bin/login

Since Yun firmware has login disable, we have to re-enable it and re-compile firmware.

Thanks sonnyyu, i beleive we're heading in the right direction now. Sorry for calling Yùn a toy, but if it was all it took to take this matter seriously, then it was worth the shot... lolll :slight_smile: After solving this problem, Yùn will greatly benefit from it, as commercial developers will now take it more seriously.

Now, having the console set to "/bin/login" in init setup is a must, when security is an issue. From what i can understand when you're talking about the firmware is that the Linux bootloader has it disabled (correct me if i'm wrong). When can we expect a version of the firmware with "/bin/login" enabled?

Thanks.

19

Robin2:
I can think of mechanical-type reasons why you might not use a Yun in a production system but I think your comment is specifically related to security issues.

You are right Robin, my post is all about security issues. When we developers (analysts) are making proof of concept, we have to justify many things before our project gets approval from IT management. Besides having to prove the utility of our project, security is the biggest obstacle we have to go through. As is (Yùn as it is), my project does not stand a chance of passing the security risk assessment. I think that Yùn is worth having to put a little effort into it, so we can make it a bit more secured. I think sonnyyu is definitely heading in the right direction.

20

PapaRazzzzee:
After solving this problem, Yùn will greatly benefit from it, as commercial developers will now take it more seriously.

I don't think commercial developers will ever take any Arduino, Raspberry Pi, Beaglebone PCduino, NetDuino, etc seriously. As a commercial developer myself, I don't see a commercial product being based on a rapid development platform. Every commercial embedded product with which I've been involved over the years has required custom hardware, because using a general development board would be too expensive, have the wrong form factor, be locked into a sole source, and myriad other reasons.

Sure, a serious developer might use a rapid development platform as a prototype, or as an early development target until the custom hardware is available, but I simply don't see it being part of a viable commercial product.

In my mind, the Arduino lineup, including the Yun, is squarely aimed at the amateur hobbiest, not at the commercial developer. There may be some rare situations where it may be used by a commercial developer, but I just don't see it being a common occurrence.

Now, having the console set to "/bin/login" in init setup is a must, when security is an issue.

This will of course, break the Bridge library. Its initialization sequence is to send a command to ash running on the the Linux serial port, and that command starts the Python code that implements the Linux side of things. That initialization sequence will now need to be updated to include a state machine to check whether it is currently logged on, send a username, then send a password, then finally start the required Python code. A significant increase in complexity (with a corresponding increase in the chances for problems) that only benefits a very narrow segment of the population. I don't see the benefit of introducing additional complexity and failure points for a small target audience that probably isn't really there: it will just help to alienate the actual target audience who already seems to have trouble coping with the simplified interface.

From what i can understand when you're talking about the firmware is that the Linux bootloader has it disabled (correct me if i'm wrong).

I believe you're wrong. The bootloader has nothing to do with that, it is a function of inittab and the features compiled into the kernel and associated utilities. The bootloader basically just gets the kernel into memory and then starts it. Of course, the bootloader has its own security issues and potential attack vectors.

When can we expect a version of the firmware with "/bin/login" enabled?

I wouldn't hold my breath. If that's a feature you want (and as far as I know you're the only one to request it so far) you will likely have to build your own custom system. Personally, I would hate to see the development team spend their time on this when there are so many more pressing issues that need to be resolved (like making basic operation more reliable, for example getting the Yun's network interface to consistently appear in the IDE port menu.)

PapaRazzzzee:
As is (Yùn as it is), my project does not stand a chance of passing the security risk assessment.

It's not intended to pass such an assessment. It's one thing to build a proof of concept on a Yun, but if your final project is going to built using actual Yuns, then I think you will have a bigger problem getting it past your project management and finance departments, and the blessing from the IT department will be the least of your concerns.

I think sonnyyu is definitely heading in the right direction.

I may be wrong, but I think sonnyyu is helping YOU make YOUR Yun more secure with a custom solution, and is not setting a new direction for the product in general.