dev: add a note on what we consider to be an attack surface in AP#7359
dev: add a note on what we consider to be an attack surface in AP#7359peterbarker wants to merge 1 commit intoArduPilot:masterfrom
Conversation
|
Maybe we should put this on a new page? Maybe a page dedicated to security issues.. it could link to mavlink signing for example |
Open to the concept, but I thought this did belong under our "design decisions" thing. And yeah, should definitely be linking to mavlink signing if we have a page for that. |
|
I support the intent of this. Good idea. |
|
needs a reviewer approval from @rmackay9 since he had a suggeston |
|
I'll create a new OEM Security (or something like that) wiki page and we can include the advice there |
|
As per today's Dev call discussion I agree it should be it's own page, but not necessarily "OEM" @rmackay9 - anyone might be interested in securing their platform even if not an OEM. Perhaps "Security and Hardening Guide" This should probably also talk about MAVLink signing, and the "lock down parameter changes" capability. |
|
|
||
| ArduPilot works in a resource-constrained environment. We can't afford all of the sanity checks that we might otherwise include. | ||
|
|
||
| To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be trusted, for example. |
There was a problem hiding this comment.
| To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be trusted, for example. | |
| To this end, we do not consider every input to the autopilot firmware potentially malicious. We trust our SPI-connected inertial sensors to be well behaved, for example. |
Just a little odd having "trust" in there twice.
6 participants
No description provided.