[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Pantelis Antoniou <panto@intracom.gr>]

Wolfgang Denk wrote:

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