DR-003-ARCH-ACL-Concept: Generic Format for Access Control List

[christianbe9]

Introducing a common format for an Access Control List (Crypto, SOME/IP,
IPC and further potential usecases), such that it is
only required to use one common parser, one common format for reviews
and also one common "ACL Manager" aka editor for ACLs and also compiler
for the ACL into a binary format.

[github-actions]

The created documentation from the pull request is available at: docu-html

[GuruprasadBhatL]

A few generic questions :

1. Is JSON as a config format centrally approved in eclipse/score ?
2. Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
3. How is relationship established between ACL config and config of individual features like Crypto/LoLa.

[GuruprasadBhatL]

Would like to understand significance of criticality in the current context.

How does it influence ACL configuration.

[christianbe9]

As we do an ACL my question is: should we include criticality in the config as well to do a cross check/ensure such that there is no mixture "by accident" of criticality due to wrong configuration or something; i.e. can a ASIL application and QM application both interact via one IPC which should not be the case afaik. So this is not a security thing, question is if we also should use this for safety purpose or not.

[GuruprasadBhatL]

what is monitor right ?

[christianbe9]

Idea behind monitor is (I'm not sure how valid) is only related to IPC, for SOME/IP and crypto its same as read, for IPC the idea is to have only read permission to data and control plane, so that a montoring application cannot interfere with the normal behaviour, however that means you could have partial reads from control plane, therefore control plane might be monitored but not so sure how good of an idea it is. Concrete example was for a Intrusion detection, health monitoring, etc.; e.g. you could check if somebody is blocking in the control pane for too long

[christianbe9]

A few generic questions :

1. Is JSON as a config format centrally approved in eclipse/score ?
   I would say yes, as all other components (e.g. lifecycle) are also using json as config format
2. Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
   No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.
3. How is relationship established between ACL config and config of individual features like Crypto/LoLa.
   ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
   Based on the ACL the enforcement is then done in each component

[ChansAlive]

A few generic questions :

1. Is JSON as a config format centrally approved in eclipse/score ?
   I would say yes, as all other components (e.g. lifecycle) are also using json as config format
2. Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
   No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.
3. How is relationship established between ACL config and config of individual features like Crypto/LoLa.
   ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
   Based on the ACL the enforcement is then done in each component

Hi,

ACL config is input to Crypto lib. Considering we have a library daemon architecture for crypto stack, is this still valid? Would this be crypto daemon or still crypto lib?

[christianbe9]

A few generic questions :

1. Is JSON as a config format centrally approved in eclipse/score ?
   I would say yes, as all other components (e.g. lifecycle) are also using json as config format
2. Is the proposal is to have ACL configuration for all features (Crypto/LoLa/SomeIP) in one file ?
   No, this can be, but must not. I just put everything into one file as the idea is to have everything in the same format and have one parser capable of parsing all the properties. So you can have 3 configs (1 IPC, 1 SOME/IP, 1 Crypto) or 2 configs (1 IPC & SOME/IP, 1 crypto) or 1 config containing all thats up to the integrator.
3. How is relationship established between ACL config and config of individual features like Crypto/LoLa.
   ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
   Based on the ACL the enforcement is then done in each component

Hi,

ACL config is input to Crypto lib. Considering we have a library daemon architecture for crypto stack, is this still valid? Would this be crypto daemon or still crypto lib?

Yes, that was bad wording by me; so ACL would be input to Crypto Daemon (in a setup where you have a mw:crypto for the application which handles the IPC to the Deaemon using LoLa and a Daemon which actually handles the jobs). The crypto lib itself will be part of the application, so it will not include the ACL check (as application would check itself then).

[GuruprasadBhatL]

Original Question : How is relationship established between ACL config and config of individual features like Crypto/LoLa.

Response :
ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component.
Based on the ACL the enforcement is then done in each component

Follow up question :

How is ACL format enforced in config of SomeIP/Crypto ? is is there a way for SOMEIP/Crypto config to inherit (enforce interface schema ) from ACL JSON schema ?

if this is clarified, I have no further questions.

[christianbe9]

Original Question : How is relationship established between ACL config and config of individual features like Crypto/LoLa.

Response : ACL config is input to Crypto lib, LoLa and someipd; i.e. all 3 include the parser lib and use the acl, either from the same path or from 3 different paths, so the path where this ACL is located is configured per component. Based on the ACL the enforcement is then done in each component

Follow up question :

How is ACL format enforced in config of SomeIP/Crypto ? is is there a way for SOMEIP/Crypto config to inherit (enforce interface schema ) from ACL JSON schema ?

if this is clarified, I have no further questions.

From my side fine, makes sense, we can define it such that all ACLs must inerhit this ACL JSON schema included here.

And then if some component needs something in addition we update the main ACL JSON schema such that it always remains central.