[Ovmsdev] Command security

Michael Balzer dexter at expeedo.de
Sun Mar 18 17:13:53 HKT 2018


Full ack.

Metrics contain even more sensitive information like the GPS position of the car.

Is there a reason to a) keep "echo" open and b) not move it into the "test" framework?

The "help" command in its current form has a very precise view of itself :)

How about something like this:

Enter a single "?" to get the root command list.
Commands can have multiple levels of subcommands.
Use "command […] ?" to get the list of subcommands and parameters.
Commands can be abbreviated, push <TAB> for auto completion at any level.
Use "enable" to enter secure (admin) mode.


Regards,
Michael


Am 18.03.2018 um 09:43 schrieb Mark Webb-Johnson:
> Steve,
>
> Thanks for this. Very helpful at this critical stage.
>
> In general, I think your criteria is correct:
>
>>     My assumption going in is that all someone should be able to do before
>>     enabling is to look at status that does not include sensitive info.
>
>
> When not in secure mode, only very basic stuff should be usable. So, boot, enable, echo, exit, help, etc, are all ok. The ‘time status’ is fine, but no ‘time
> set’. etc.
>
> The others should not be visible, imho. Metrics, Module, obdii; all should be secure mode only.
>
> To answer your specific questions:
>
>> 1. obdii, server and simcom appear to allow their full functionality,
>> including starting and stopping operations, in non-secure mode.  That
>> seems wrong.
>
> The “simcom status”, “server v2 status”, “server v3 status” are fine, but the others should be secure only.
>
>> 2. event, metrics and notify all allow tracing to be turned on or
>> off.  Is that safe?
>
> I think these should be secure only.
>
> Metrics should probably be secure only as there is some private information shown there (such as ICCID, etc).
>
>> 3. time allows setting the time in non-secure mode.  That may not be
>> critical in this system, but could mess up timed activities.
>
> The “time status” is fine, but “time set” is secure mode only.
>
>> 4. Setting the vehicle module should require being enabled, no?
>
> Yes. Secure mode only.
>
>> 5. Is it OK to list the metrics in non-secure mode?  Is any of that
>> information sensitive enough that it should be prevented?  (We don't
>> have the option to show some metrics and not others at this point.)
>
> No. Better not. Secure mode only.
>
>> 6. The module command only allowed the subcommand 'factory' which did
>> not allow any subcommand, so the right fix there is to just make the
>> whole command require secure mode.  This observation exposed a bug in
>> the code to construct the usage string, which I fixed.
>
> Yes. Secure mode for the whole thing.
>
> Regards, Mark
>
>> On 18 Mar 2018, at 3:23 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>
>> Mark asked me to check whether the 'secure' flag is set appropriately
>> in the various command invocation contexts.  I began with the console
>> command list where there are a number of questionable settings.  My
>> assumption going in is that all someone should be able to do before
>> enabling is to look at status that does not include sensitive info.
>> However, there are several commands that do more.
>>
>> All of these commands are at least partially enabled in non-secure
>> mode:
>>
>> OVMS > ?
>> boot                 BOOT framework
>> echo                 Test getchar
>> enable               Enter secure mode
>> event                EVENT framework
>> exit                 End console session
>> help                 Ask for help
>> metrics              METRICS framework
>> module               MODULE framework
>> network              NETWORK framework
>> notify               NOTIFICATION framework
>> obdii                OBDII framework
>> server               OVMS Server Connection framework
>> simcom               SIMCOM framework
>> time                 TIME framework
>> vehicle              Vehicle framework
>>
>> The harmless ones are 'boot', which just shows status, 'echo', 'exit'
>> and 'help'.  Of course, 'enable' needs to be here to change state.
>> But I have questions about all the others:
>>
>> 1. obdii, server and simcom appear to allow their full functionality,
>> including starting and stopping operations, in non-secure mode.  That
>> seems wrong.
>>
>> 2. event, metrics and notify all allow tracing to be turned on or
>> off.  Is that safe?
>>
>> 3. time allows setting the time in non-secure mode.  That may not be
>> critical in this system, but could mess up timed activities.
>>
>> 4. Setting the vehicle module should require being enabled, no?
>>
>> 5. Is it OK to list the metrics in non-secure mode?  Is any of that
>> information sensitive enough that it should be prevented?  (We don't
>> have the option to show some metrics and not others at this point.)
>>
>> 6. The module command only allowed the subcommand 'factory' which did
>> not allow any subcommand, so the right fix there is to just make the
>> whole command require secure mode.  This observation exposed a bug in
>> the code to construct the usage string, which I fixed.
>>
>> So, basically, the question is what do we want someone to be able to
>> do in non-secure mode?
>>
>>                                                        -- Steve
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180318/a3983fe9/attachment-0001.html>


More information about the OvmsDev mailing list