3

Let's say I create a device which has an embedded Linux box in it (for example, a Raspberry Pi). After booting up, it starts the main application which is designed to provide the UI for the device.

The simplest way to produce more of them, is just to set up everything on one specific device, set the users, privileges, configure the booting process, install my software, and then create an image of the SD card. Installing that image to other SD cards gets me identical clones of the original device, which I can now ship.

However, this can lead to a serious vulnerability. As all the users will have exactly the same root password, all it takes is one user figuring it out (having access to the physical devices counts, as far as I know, for completely compromised security), and that one user might then use this knowledge to compromise the devices of other users (the device is expected to be used while connected to a network)

How can one mitigate this risk?

The software also needs to know the root password (as it needs to configure some hardware registers for the peripherals), so does this mean I have to compile the executable for each of the physical devices separately with separate root passwords, and create the users on each device separately, then manage to copy the correct software to the correct machine? This seems like a management nightmare.

  • 2
    You could disable root log in (should be anyway) and remote log in, if you don't need it. Also, if that's not sufficient for your szenario, you could write yourself some setup script that does the setup for you. – Tobi Nary Apr 14 '16 at 9:11
  • @SmokeDispenser : In that case, if this community thinks that just disabling the root login and remote login would be sufficient, and having the same root password on every device doesn't have any serious vulnerabilities I forgot to think about (and that this is common practice), I could accept a slightly expanded version of your comment as an answer. – vsz Apr 14 '16 at 10:16
  • It's not an answer because we can not determine if that would be sufficient without way more information about the product, the configuration, the setup, your threat model and the use cases. – Tobi Nary Apr 14 '16 at 10:23
  • "The software also needs to know the root password (as it needs to configure some hardware registers for the peripherals)" - this statement seems extremely dubious to me. I suspect there are many ways of solving this without having to store the password on the device in a recoverable format. Remove this from your requirements and the problem becomes a lot simpler. I encourage you to post a further question asking how to execute a program as root without logging in as root to see some of the options. – symcbean Apr 14 '16 at 15:37
  • @symcbean : Yes, for example I could put only the privilege-requiring parts into a separate program and add it to the sudoers list, or use setuid and give its ownership to root, but that would add a communications overhead between it and the main application. I'm still considering whether the possible risks are worth the overhead. – vsz Apr 14 '16 at 19:29
2

Consider to build your application in a way that hardware access and other high privileged actions are done by a service which is running as a privileged user (Try to avoid using root) and has a stable and well defined interface while all other logic is done without this privileges. This will reduce the attack surface and you don't need to store non-hashed passwords on the device.

Another simplified way could be to create a minimalist binary which handles the hardware interaction which you could call from your application. This binary could have the setuid permission for root set like @paj28 already suggested. However this will have some impact on the performance of the whole process since calling a external binary creates more overhead.

As @SmokeDispenser already stated it's best practice to harden the root account by disabling local and remote login and by randomly generating individual passwords for every single device. This can be done by using a setup script.

2

There's two main approaches:

Force the user to pick a password

The device ships with no password. The setup process forces the user to pick a password. This may mean that the device is unprotected until the user does that - but that's probably not a big problem.

Ship with a random password

After you clone the image onto an SD card, update the root password to a random value. You need to communicate the password to the user, which is often done by printing it on a sticker and attaching this to the inside of the box.


You mention the software needs to know the root password. That can be avoided; for example you could make your software setuid-root.

  • I'd go with creating a password based on the hash of the device serial number with a secret salt - that way its recoverable without having to maintain records (unless the serial number is exposed elsewhere). – symcbean Apr 14 '16 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.