No events planned
What follows is an architectural diagram of the way RSBAC works internally. We will first describe here each step RSBAC goes through, when a new event occurs (or if you prefer, an action is performed on the system).
You do not need to understand everything right away, as separate parts of RSBAC will be explained in more details further on, but keep this page as reference.
|1, 2, 3||The Access Control Enforcement Facility (AEF) intercepts every security relevant system calls, compiles them and performs a request to the Access Control Decision Facility (ADF).|
|4||The ADF will ask every Decision Module1) for its opinion on this request.
The modules look into the Data Structures to decide upon the request and answer the ADF.
|5||The answer from every module is combined by the ADF with a restrictive metapolicy, giving a final answer that is sent back to the AEF.|
|6||In case the ADF decided to deny the access, the AEF will return an error (with associated control data if necessary) to the calling process. In case of error or denial, we stop here.|
|7||The object is accessed normally if access has been granted previously (in 6).|
|8||If everything went without denial or error, the AEF sends a notification to the ADF.|
|9||The ADF tells the modules to update their attributes from the data structures.|
|10||The ADF sends back an acknowledgement to the AEF.|
|11||Control and optional data are returned to the process.|
In the next sections, we will explore individual components in detail.