Remember the System base page in this chapter ?

We will now re-use it but add information about what needs to be done to achieve the system base protection with different modules.

The selection of local users and the services they use to login are easily mapped into an AUTH module configuration. The same module can also deny access to unauthenticated users, e.g. using RSBAC User Management or with a separate daemon, while the RC model encapsulates these mechanisms to prevent any misuse.

Examples:

• /bin/login should allow user id 0 and 400 to login (root and security officer)
• /usr/sbin/sshd should allow local users ranged from user id 1000 to 2000 to login
• Some daemons call setuid to change their user id (usually from 0 to another) and need this right granted

The File Flags can only help in Base Protection, service encapsulation is not possible with this module. However it is quite useful.

• Filesystem infrastructure:
  • Set no_rename_or_delete on all important dirs and files (it won't be inherited, don't worry about subdirectories)
  • Also set no_mount if the directory is not a mount point (e.g. /bin, /sbin ..)

• Protect executables, libraries, configuration files, kernel objects and boot files:
  • Set flags search_only (only applied on dirs) and read_only.
  • Optional: set execute_only on binary executables (scripts will however need READ_OPEN etc. so don't put it everywhere)

• Protect against execution of uncontrolled files:
  • unset flag add_inherited on all objects named above, then set flag no_execute on / (or e.g. /home only)

The JAIL module can only encapsulate services, but it cannot help in Base Protection.

You should start each service in a JAIL, e.g. with the rsbac_jail wrapper program. Replace chroot() calls with rsbac_jail() in sources.

Allow only required Linux capabilities and create sub-jails whenever useful. Jails can be used for almost all services, but they need some tuning with parameters to allow some accesses.

The RC model is good for both Base Protection and Service Encapsulation.

For each category of objects, the same scheme is applied: Add a new object type, define the type compatibilities for every role as necessary and assign the type to all objects in this category.

The RC model allows copying roles and types with all type compatibilities to help with this task. This is specially useful, if more roles or types with similar rights have to be added later. The rc_get_item tool can also produce a complete cross referenced overview of all roles and types with their respective access rights for review, which proved very helpful in practical experience.

Whenever necessary, a separation of duty scheme and extra roles, e.g. for installation and configuration, can be set up.

Usually, a rough approximation is enough to begin the configuration. The detailed logging scheme of the RSBAC framework will show all prevented accesses later, which can be used to fine tune the configuration by granting or not granting access after evaluation.

Service or network client encapsulation using the RC model generally follows the scheme of defining a role for each service and specifying all necessary accesses to the existing types. This role gets assigned to all service programs, either as initial role, e.g. for user specific services, or as forced role, e.g. for common or anonymous services.

Whenever a service needs special access to its own specific data, or different accesses to objects of the same type, another type is introduced and all existing roles get their specific compatibility settings to this type. In most cases, the existing type is copied and then adjusted.

Some services have different access patterns under certain circumstances, e.g. a Webserver running a CGI script. If another program is involved, it can get its own forced role value, otherwise the service program must be modified to switch to a compatible role or the superset of all accesses must be granted.

The protection against other services is easily provided through an extra process type set as Default process type in the role settings. Which of the three attributes for create, execute and chown is best suited for this task depends on the service behaviour.

Finally, a set of network templates with individual RC type values allows to control which client can access which service, as long as one of the two connection endpoints is on the local system. It can also prevent that unauthorized programs bind to a local standard service port to intercept confidential data from remote clients.

The ACL model is good for base protection and has limited use for service encapsulation.

• Protect executables, libraries, configuration files, kernel objects, boot files and /tmp dirs: Set inheritance mask to filter out unneccessary rights to these objects

• Protect against execution of uncontrolled files: Explicitly grant SEARCH, READ_OPEN, READ, CLOSE and EXECUTE right for group 'Everyone' to all executables, then remove EXECUTE right from FD :DEFAULT:

• Protect devices: Set inheritance mask to filter out unneccessary rights to these objects, then explicitly grant necessary accesses for special task users (or groups / RC roles), e.g. for fsck.

• Authentication data: Only user, group or RC role based protection is possible. Set inheritance masks to filter out unneccessary rights to these objects, then explicitly grant necessary accesses for special task users (or RC roles)

• Protect network resources: Define network templates for all identified local and remote network endpoints. As inheritance goes from NETOBJ to matching template to NETOBJ default ACL, set template's inheritance mask to filter out unneccessary rights to the network objects covered by each template. Set ACL entries on the templates for all subjects as desired.

• Service encapsulation: Only user, group or RC role based protection is possible. Group everyone might have to be replaced by a controlled group. Set service user rights: Access own dirs/files as necessary, SEARCH, READ_OPEN, READ, CLOSE and MAP_EXEC libraries, only SEARCH :DEFAULT: for path resolution. Optionally: Allow read and write on /tmp dirs (try to avoid). Give no access to other FD objects, device access as required.

Set individual logging for the identified objects and requests. Set individual user and program logging for identified requests. Use RSBAC own logging source at /proc/rsbac-info/rmsg for reliable logging.

• Softmode: Optimize your setup without locking yourself out, use global and individual module softmode.

• Individual user (RC role, remote IP) /tmp dirs with symlink redirection:

mkdir /tmpdir
mkdir /tmpdir/tmp<uid> (mkdir /tmpdir/tmp<role-nr>)
rmdir /tmp
ln -s /tmpdir/tmp /tmp

• Allow security admins to browse all dirs without suid root: Use CAP model to set user min_cap DAC_READ_SEARCH

• Hide other user's processes: Use CAP module's process hiding kernel parameter rsbac_cap_process_hiding.

• Secure delete for sensitive data: Use FF flag secure_delete or RC FD type attribute

• AUTH learning mode: Let the system learn required AUTH capabilities.

• ACL learning mode: Add missing ACLs for single users and objects automatically.

• Separate logging source: Use rsbac_nosyslog and rklogd to log invisible from root

• TTL-Settings: Use lifetime limits for many AUTH, RC and ACL settings.

Table of Contents: RSBAC Handbook