DBC/VSS security model

[fulup-bzh]

I'm currently working on a new CAN/DBC/VSS binding in Rust to replace our current C++ version. In this refit work, I'm wondering about VSS security model mapping. Within our standard security model, each api/prefix/verb may inherit of a privilege security tag. With this model as soon as a privilege is set within the api/prefix/verb three any branches/leaves following inherit of the privilege, and I get the impression that this model could work with VSS.

I currently enforce privileges on top of DBC with an overlay configuration that is somehow similar to your DBC/VSS overlay. Nevertheless I'm wondering where those privilege tags should fit within VSS. Should I add a new security tag within the DBC/VSS overlay file, or does VSS already have something to handle message ACLs ?

Note: as today I only publish the initial Rust low level interface with sockcan, the rest should follow. https://github.com/redpesk-labs/canbus-rs

[erikbosch]

Hi Fulup!

It has sort of been agreed in COVESA that the "core" part of VSS does not concern how signals/data are access or transmitted, and that also means that security model is not in the scope of "core" VSS. That is to a big extent left to downstream projects like KUKSA.VAL or W3C VISS. There are however discussions within COVESA if COVESA also should provide guidelines or even recommendations on how security can be managed in down stream projects, and one potential solution of this could be to define recommended keywords to use for specifying access requirements for a specific signal.

KUKSA.val Databroker authorization model relies on tokens specifying explicit paths, so there no extra config in VSS overlays are needed for runtime operation of Databroker (but could be useful for generating tokens). W3C VISS has a partially different concept where metadata might be need for the server to evalute if a request shall be accepted.

So the answer in short - No, there is not yet any methodology defined by VSS/COVESA to specify required access for VSS signals. If you would come up with a good set of keywords/tags (to be used in overlays) to specify/control access to VSS signals, then I think it would be interesting to discuss within COVESA if your keywords/tags could become a recommended/reference solution for solving the problem.

[fulup-bzh]

Thank you for the answer. In this case I still stick to our current security model, where we use per-verb privileges. As I did not find reusable native VSS parser in Rust, I started to write one. My next step will be to merge VSS with DBC and NMEA2000 overlay.
This being said, the fact you do not normalize how to access signal, kill any interoperability strategy, which should be one of VSS goal, isn't it ?

[erikbosch]

We have migrated CAN Provider (dbcfeeder) to a new repo. Long term my intention is to close all dbc/can-related issues in this repository. If we see the issue as still interesting or relevant we could create a new issue in the new repo, possibly referencing the old issue in the repository.

Suggested way forward:

• I will migrate selected issues early 2024
• If this issue has not been migrated but you want it to remain open please comment.
• Remaining issues no one seems to be interested in will be closed around 2024-03-31