[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot
Pantelis Antoniou
panto at intracom.gr
Fri Apr 18 12:31:10 CEST 2003
Wolfgang Denk wrote:
>Hi,
>
>in message <3E9FA26F.3000906 at 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.
>
>
I believe there's a misunderstanding here. I'm not talking about having
bulletproof security. A technical savy user which has physical access
to the device will be able to do what ever he/she want.
I just want to prevent casual tampering with the device settings.
This is not meant to keep something secret, but rather to keep
support costs low.
The two level security is probably overkill, but a single
level is necessary in my application.
>
>>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.
>
>
Unfortunately the administrator or the support technicians need this access
sometimes for troubleshooting, when the web interface is not available
because of faulty network settings, or some network topology change.
>
>>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".
>
I see nothing there about a password, and I'm aware of the autoboot feature.
>
>
>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.
>
>
Nice idea.
>
>>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.]
>
>
The passwords will be stored encrypted.
There will be no master passwords. If the password is lost
a button pressed during the boot sequence, or a key sequence will
reset the device state to that after it left the factory.
It is then up to the administrator to restore the device to
functional status.
At a site the passwords are the same for each device. It's not
like each device will have it's own different password.
And yes, the full source code will be provided.
>
>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.
>
I don't intent to do that. I am not striving for maximum security,
just a way to prevent non determined people of messing with their device
out of boredom.
Site security is a problem for the resident BOFH.
I just have to provide him/her with the tools to do their job.
>
>Best regards,
>
>Wolfgang Denk
>
>
Regards
Pantelis
More information about the U-Boot
mailing list