[Ovmsdev] Command security
Mark Webb-Johnson
mark at webb-johnson.net
Sun Mar 18 17:35:44 HKT 2018
Done.
> On 18 Mar 2018, at 5:13 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> 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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180318/b9e6a648/attachment.htm>
More information about the OvmsDev
mailing list