Creating new roles

Thu Jan 24 11:25:12 UTC 2013

On Thu, 2013-01-24 at 08:01 +0100, richard -rw- weinberger wrote:
> Hi!
> 
> What is the preferred way to create new roles?

Use the provided API's where possible

> I'd like to create a role like sysadm_r but with less rights.

If your requirements are really a simple as you suggest then you can
clone and modify the cloned userdom_admin_user_template() API and use
that as a base for you role

> Do I have to patch the selinux-policy rpm?

No

> 
> Is somewhere defined (in written text) what exactly the current roles
> are allowed to do?

The Fedora SELinux user guide touches a little on SELinux users but not
on roles to the best of my knowledge.

One can use the HTML representation of the user domain API's [provided
by the selinux-policy-docs package

I can give you a very rough overview of the applicable API's but it is
near impossible to document all the specifics because:

Not all rules apply to all distributions.
Rules are subject to change.
The volume of rules.

Here are the common API's are their main characteristics:

1. userdom_base_user_template
=============================

The description says:

The template containing the most basic rules common to all users.
This template creates a user domain, types, and rules for the user's tty
and pty.

So it is a base for all roles. All roles are built on this base

Why is it a separate template?

This template can be used to "secondary" roles. Roles that can be
accessed via sudo or new role from "primary" roles.

A practical example is the webadm_r role. This is a web administrator
role.

The characteristics of this template are that it provides a minimal
role. It does not provide access to home, temporary and tmpfs, It does
not allow access to change password.

You cannot use it to log in to a system. Hence why i call it a secondary
role. It relies on the existence of a primary role.

This is a good base for any privileged role in my view as users should
not be allowed to log in to the system in a privileged role directly.

2. userdom_login_user_template
==============================

The description says:

The template for creating a login user. This template creates a user
domain, types, and rules for the user's tty, pty, home directories, tmp,
and tmpfs files.

So it is a base for all login roles. All login roles are built on this
base.

This API is built on userdom_base_user_template

So it is the base user template with rules appended that are needed to
log in and maintain a home, temporary and tmpfs. Additionally it
provides access to change the user password.

This is a primary base role. It should provide a base for roles that can
be used to login directly to the system.

3. userdom_restricted_user_template
===================================

The description says:

The template for creating a unprivileged login user. This template
creates a user domain, types, and rules for the user's tty, pty, home
directories, tmp, and tmpfs files.

This API is built on the userdom_login_user_template.

The difference is that this API allows for a least privilege SSH login
user. So it is a primary restricted login user role with the rules
needed to login via SSH only.

4. userdom_restricted_xwindows_user_template
============================================

The description says:

The template for creating a unprivileged xwindows login user. This
template creates a user domain, types, and rules for the user's tty,
pty, home directories, tmp, and tmpfs files.

This API is built on the userdom_restricted_user_template.

In addition to the rules that allow a login user role to login via SSH
this primary restricted login role also allows for login in via Xwindows
and provides for minimal functionality in a GUI environment.

5. userdom_unpriv_user_template
===============================

The description says:

The template for creating a unprivileged user roughly equivalent to a
regular linux user. This template creates a user domain, types, and
rules for the user's tty, pty, home directories, tmp, and tmpfs files.

This API is build on userdom_restricted_xwindows_user_template

It basically adds rules that transform a restricted Xwindows user to a
regular unprivileged user.

6. userdom_admin_user_template
==============================

The description says:

The template for creating an administrative user. This template creates
a user domain, types, and rules for the user's tty, pty, home
directories, tmp, and tmpfs files.

The privileges given to administrative users are:

Raw disk access
Set all sysctls
All kernel ring buffer controls
Create, read, write, and delete all files but shadow
Manage source and binary format SELinux policy
Run insmod

This API is *NOT* built on userdom_unpriv_user_template, but instead is
built on userdom_login_user_template and adds a template that has rules
that are common to all unprivileged login users called
userdom_common_user_template

It adds rules to transform the above to a privileged primary login user
role. It provides some rules required for general system administration.

In a non-MLS policy model this includes access to security
administration.

7. userdom_security_admin_template
==================================

The description says:

Allow user to run as a secadm. This is a templated interface, and should
only be called from a per-userdomain template.

This API is *NOT* built on any API. Instead it is a template to extend a
unprivileged or privileged primary login role with rules required to
maintain the security aspects of system administration.

In a non-MLS policy model this template is used as a complement to the 
userdom_admin_user_template

In a MLS environment this API is used together with
userdom_unpriv_user_template.

It will allow one to create  privileged primary login user role that
provides some rules required to for general security administration.

My take on the preferred method of creating privileged roles.
=============================================================

1. Do not use privileged login user roles.

Same as root should (almost) never be able to log in directly as root,
users should never be able to log in directly in a privileged domain.

Instead provide a primary restricted or unprivileged login user with
access to a secondary privileged role via SUDO or SU together with
newrole.

2. Use the userdom_base_user_template to create a secondary privileged
role. Tailor it to your specific requirements.

The use primary restricted or unprivileged login role will need access
to SUDO, SU togeher with newrole and will need access to the secondary
privileged role.

The various system service policy modules provide API's to allow for
administration of that services assets. Example: apache_admin provides a
caller access to all the rules required to maintain a web server.

References:
===========

The selinux-policy-doc package provides a HTML view of the various API's
You can peruse them from your web browser.

One can find available interfaces,templates, patterns, permission sets
and other macros in /usr/share/selinux/devel/include

One can find a Linux object class and AV perm reference here:
http://www.selinuxproject.org/page/ObjectClassesPerms

One can browse the Fedora selinux-policy source here:
http://git.fedorahosted.org/cgit/selinux-policy.git/

Learn how to read policy (whether its is raw policy or processed
policy), as well as Access Vector cache events and to use tools like
seinfo and sesearch.

> E.g. user_u seems unable to see system processes. Where can I read
> more about such
> limitations?
> 