=>  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

Areas of Use

RSBAC is useful on any server or client system which needs more than the very basic protection than standard Linux can provide. As a matter of fact, any production system, including desktop and embedded devices require a decent level of protection, as it is today’s big problem in the software industry. However, we will present you a few good examples where RSBAC fits well.

Firewall

The RSBAC system does not provide packet filtering services, which have been part of standard Linux kernels for a long time. Instead, it restricts network access on a logical level of connections and endpoints. Additionally, it can be used to protect the packet filter configuration of the standard Linux kernel as well as all proxy services and administration accounts on the firewall system.

The proxy services can be encapsulated so that they cannot access anything outside their data caching and logging environment. Additionally, they can also be limited in the network resources they can access. In a typical RSBAC firewall setup, the protected internal network is inaccessible from all services, although all proxies work fine.

Administrator login can be enforced to certain login paths, e.g., the local console only. Packet filtering setup can be restricted to a boot script, which cannot be changed by the system administrator.

Mailserver

The Sendmail mailer system is usually run under the system administrator account. It is well known for its bad security history.

Even with a more securely designed mailer system like Postfix or Qmail, we still need to encapsulate services, like the POP3, IMAP, Web and local mail access services. On virtual mail servers, the different areas can be cleanly separated through RC roles and types.

Webserver

Using together Apache and mod_rsbac, it is possible to separate every virtual host on a web server. Thanks to this module, it is not necessary for Apache to restart it’s own processes while switching credentials (like SuExec would do). This may lead into a substantial performance gain and flexibility.

Application Server

In this context, the term application server is meant to describe a server, which interactively runs applications for users, but displays their output on each user’s workstation.

Generally, such servers are not difficult to protect. After the usual base protection, all user accounts are encapsulated into one or more RC roles, which can only execute some programs and have very limited access to local and to network services. The user login services are restricted to legal user accounts by the AUTH model.

Desktop

While you can bring a full blown policy on a desktop system, it is often a tedious work requiring constant updates and testing, to keep user’s desktop flexibility at the level they expect. It is however common to encapsulate a few applications on a desktop system, like the browser and mail client.



Table of Contents: RSBAC Handbook
Previous: Design Goals
Next: Compatibility

 

documentation/rsbac_handbook/introduction/areas_of_use.txt · Last modified: 2008/02/28 17:39 by kang
This website is kindly hosted by m-privacy