Current version
Git/Latestdiff: 1.5.6
Latest Snapshots
Produced after each commit or rebase to new upstream version
GIT
RSBAC source code, can be unstable sometimes
No events planned
The Access Control Decision Facility (ADF) contains a powerful logging system. It is possible to specify the event to be logged in dependence of the request and target type, user, executable and target object (file, fifo, symlink, directory, device, network device or network object (through template)). Some of these features have to be turned on in the kernel configuration.
Kernel logging options for 1.2.5+
│ │ [*] Individual file/dir/dev object logging │ │ │ │ [*] Individual user logging │ │ │ │ [*] Individual program logging │ │ │ │ [*] Log program file │ │ │ │ [*] Log full path │ │ │ │ (512) Maximum path length (256 - 4000) │ │ │ │ [*] Pseudonymous logging support │ │ │ │ [*] Pseudonymize filesystem objects │ │ │ │ [*] Syslog rate limit │ │ │ │ (1000) Default allowed message lines per second │ │ │ │ [*] RSBAC own logging facility │ │ │ │ [*] Allow to disable logging to syslog │ │ │ │ --- ---------------- │ │ │ │ [ ] Log to remote UDP network socket
Logged items are the request, process ID, parent process ID, program name, real or pseudonymous user ID, target type, target ID, attribute type, attribute value, ADF decision and the names of the modules that made this decision.
For each logging switch, the log level can be set individually for each request type:
The request based logging is administrated via the switch_adf_log command line tool or the menu rsbac_menu, the current values can also be seen in /proc/rsbac-info/adf_loglevel. The individual log settings are implemented as attributes and are set via the usual tools.
As all accesses to log settings are access controlled, each model can implement its own access control scheme for their protection.
Whenever a request has run through all modules, the decision dispatcher goes through the following algorithm to decide, whether the request is to be logged. Please note that logging takes place, if at least one of these steps decides that logging is needed. So the decision 'log' terminates the algorithm.
The algorithm is also used to determine, whether an rsbac_adf_set_attr() call has to be logged - just replace result is NOT_GRANTED
by function returned an error
.
The rsbac_adf_set_attr() notification function is called from most interception points to inform the decision modules that the intercepted functionality has been performed successfully and that they should adjust their attribute values. It is also the only way to tell the decision modules about newly created objects.
What are log_levels ?
Well, in RSBAC logging system you can choose which targets to log for or not (audit for or not)
You can view the GLOBAL log settings with
cat /proc/rsbac-info/log_levels Name FILE DIR FIFO SYMLINK DEV .... ADD_TO_KERNEL 1 1 1 1 1 .... ...
Thoses are used per default on all targets. Eg, here we log ADD_TO_KERNEL requests on FILE, DIR, FIFO, SYMLINK, DEV, … targets
you have also per file/process/whatever settings of what to log, its extremely fine grained…
look into log array low and log array high with rsbac_fd_menu or others, you can log nothing, only denied, full (denied + allowed) or request Thoses are for accesses to that file now when its a process running for example, you have program based log, which logs when the program would access thoses calls while executing.
Or course this level of fine graining can be hard to manage without a tool, or a really good memory ! Defaults are fine as everything is logged.
//