Hi,
in message 3E9FA26F.3000906@intracom.gr you wrote:
We already use an OS. The problem is that the device's user/person who has physical access to it, is not supposed to be allowed to alter anything in the configuration; especially the network settings, since an error there will render the device unoperable.
In my opinion U-Boot is not the right user interface for such use, then. It is a monitor program / boot loader, the intention of which is to provide direct access to the hardware. And with direct access to the hardware you can easily work around security measures.
For example, will you disable memory dump/modify commands? Probably not, as they are very useful to the user. So what prevents a user from using "mm" or "mw" to directly modify the working copy of the environment variables in RAM?
I don't know what you want to do, but IMHO you can either prevent use of the U-Boot command line interface completely, or you will have to live with the fact that a user can do things he should not do.
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
This applies for U-Boot, too.
Think access control on a router or something similar.
Don't allow any access to the U-Boot user interface, then. Run a OS on top of it, and implement a web interface or something like that where the user actions can be controlled on a higher level.
True, it's a problem on how to implement it cleanly. We'll see how that will turn out. A first simple step will be to have a single password for entering the command mode.
This has been available since long time ago. See "doc/README.autoboot".
A relatively unintrusive method couldbe to change the "repeatable" field in "struct cmd_tbl_s" into a "flags" field, where 'repeatable' is just one bit, and one (or more) other bit(s) are used to specify a "security" level, to prevent the command from being run if the security level does not match.
Almost nothing actually, it's just a method of managing the existing settings by using a master switch.
I'm afraid this won't work as you expect. You will either render U-Boot useless, or add "security" which in fact is just window- dressing.
You allow execution of any some, but not all commands? Be careful, even simple commands can be used to do "critical" things.
I don't need "setenv" to modify the environment. "mm" or "mw" will do.
I don't need "saveenv" to store the settings. "cp" or "eeprom read", "mm" or "mw", "crc32" and "cp" or "eeprom write" will do.
How do you save ypour passwords? Unencrypted in the environment (as it is now the case) ? Guess how long I will need to find them!
You will add encryption? How will you manage passwords onthese boxen then, in case the password was lost? Ah, you will implement a secret master password? OK, I'll look it up in the source code. [And you, you MUST provide the full source code, this is GPL software.]
Sorry, but I really see no easy way to harden a box if you open the U-Boot command line interface to a customer. Change your design. Don't use a chainsaw for jigsaw work.
Best regards,
Wolfgang Denk