RSBAC Handbook
Releases
Stable: 1.3.7
for kernels:
Devel 1.4: 1.4.0-rc3
for kernels:
Full RSBAC kernels
Lazy of patching ?
Get the already rsbac-patched kernel. Choose your flavor.
Classic kernels
Includes vanilla kernel with the RSBAC patch
Enhanced kernels
Kernels including latest security fixes, goodies, and of course PaX+RSBAC
Debian repository
Also works for Ubuntu and other Debian-based distributions, of course
SVN
Cutting edge RSBAC source code, can be unstable sometimes
Events
No events planned
These Linux kernel compile benchmarks have been run on an Celeron-333 UP system with kernel 2.4.18 and RSBAC version 1.2.0-pre6. Three runs each of ‘make clean && time make bzImage’ on the same plain 2.4.18 kernel source tree in single user mode after one untimed run produced the following average times in seconds:
| Kernel type | Total time | Kernel/Sys + User | Kernel/Sys time | User/Process time |
|---|---|---|---|---|
| Clean kernel | 734.53 | 734.53 | 34.81 | 699.72 |
| Maint kernel (no modules) | 738.28 (+0.51%) | 738.28 (+0.51%) | 37.49 (+7.70%) | 700.79 (+0.15%) |
| RC + AUTH, network support, no other options | 747.52 (+1.77%) | 747.52 (+1.77%) | 43.59 (+25.22%) | 703.93 (+0.60%) |
| AUTH + ACL, network support, no other options | 749.28 (+2.01%) | 749.28 (+2.01%) | 47.34 (+36.00%) | 701.94 (+0.32%) |
| Default config: REG, FF, AUTH, RC, ACL, CAP, network support, full log settings, but nothing logged | 767.76 (+4.52%) | 767.76 (+4.52%) | 65.57 (+88.37%) | 702.19 (+0.35%) |
| All options and models, except MS | 813.44 (+10.74%) | 813.44 (+10.74%) | 104.53 (+200.28%) | 708.91 (+1.31%) |
| Full MS, no other options | 747.49 (+1.76%) | 747.49 (+1.76%) | 44.22 (+27.03%) | 703.27 (+0.51%) |
The significant kernel time increase with more models, compared to the previous v1.1.2 benchmark, is probably related to the distribution of attributes over separate lists for each module, which results in more list lookups. Also, the RC changes from fixed size role and type arrays to lists slow this model down a bit.
In larger setups, the list separation should result in much shorter lists and thus speed things up again. You can see this and the internal list optimizations in the much better MS results, where large lists of scanning results are generated.