Overview of the security framework

First of all, redpesk OS is a linux OS embedding the default security mechanisms of Linux.
This brings a solid basis for creating secured system.
The mechanisms are:

  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Capabilities
  • Namespaces

The security framework of redpesk OS adds the ability to manage permissions for services and attribution of small grained permissions.

The table below lists main security behaviors and the corresponding protection measures.

Behaviour Protection
process can’t be killed use DAC and MAC isolation
files are protected use DAC and MAC isolation
service can check client permissions use MAC and redpesk framework
client on network are checked redpesk framework and OAuth

These are also summarized by the figure below, where cynagora is a component of the framework.

access filtering

Applications and services are delivered by packages. For redpesk OS these are RPMs. When a package is installed, the content of the RPM is scanned by the security framework to get metadata about the package. These metadata are used to setup the security environment of the installed package.

Objects provided by Linux kernel are primarily protected by the setting of DAC. This protection, if required can be enforced using MAC. In both cases, redpesk is flexible enough to let architects tune the default protection.

Objects managed by services and applications (services and applications are almost the same thing, and for redpesk security framework, exactly the same thing) can be protected using the permission based security framework. To achieve that goal, applications just need names of permissions to be checked. These names are either chosen in the set of already existing permissions or created as needed in the namespace of the application.

The permissions are checked based on attributes of the requester (possibly with delegation). The attributes that can be checked are:

  • the user identity,
  • the application identity,
  • the session token.

The test of one permission is made using the permission database service named cynagora. To test the permission of a client, an application requests cynagora to evaluate if it satisfies the required permission. This can be done using the methods below:

  • use the micro-service framework facilities that incorporates test of permissions required either statically in a declarative way or dynamically through a convenient API;
  • use a convenient C library (ask for binding in other languages),
  • use the protocol of cynagora through a connection to its client interface.

The cynagora service has the ability to establish a bridge between permissions and roles. This can be leveraged for defining a role based access control.