=>  Releases

Stable: 1.5.0

  • 4.4.y

Patched kernels
Includes vanilla kernel with the RSBAC patch

  • 4.4.20
  • 4.4.21

Latest diffs
Produced after each commit or rebase to new upstream version

Enhanced kernels
Combined patches with RSBAC and PaX, less well tested

External RSBAC+PaX
Maintained by m-privacy

GIT
RSBAC source code, can be unstable sometimes

=>  Events

No events planned

Configuration

You should now have a bootable and usable RSBAC system. You are probably able to boot with the rsbac_softmode boot parameter or rsbac_auth_enable_login (see First Boot)

The next step is to understand what needs to be taken care of, i.e.: to be secured on your system.

How to separate every potentially insecure part of the system into different categories ?

How to translate the protection you need into RSBAC models ?

We can start by defining the policy1) into four distinct base categories:

Protection of the base system is necessary in any configuration. To say it straight, it partially depends on the services your system is going to run. However, we should cover most common aspects.

Once you got a layout of your base system protection, you will be able to encapsulate each service into a confined space.

But before setting up any real RSBAC policy, we will explore your current system security and what models we should apply.

Note: The actual modules/model selection chapter, which help you select the modules you will need, is a little futher in this handbook, in the chapter 5. It is however recommended to read the chapters in order, to fully understand which modules are suggest.



Table of Contents: RSBAC Handbook
Previous: First Boot
Next: System Base

1) A security policy represents the RSBAC rules which will protect your system, e.g. a policy could be to deny all access to an application by a user
 

documentation/rsbac_handbook/configuration_basics.txt · Last modified: 2010/02/26 17:53 by kang
This website is kindly hosted by m-privacy