RefpolicyBasicRoleCreation - Revision history

JoshuaBrindle: /* Roles Similar to Existing Roles */

2009-11-19T16:12:58Z

Roles Similar to Existing Roles

←Older revision		Revision as of 16:12, 19 November 2009
Line 36:		Line 36:

	== Roles Similar to Existing Roles ==		== Roles Similar to Existing Roles ==
-	If the role's user domain should be similar to user_r or staff_r, the userdom_unpriv_user_template() template should be used.	+	If the role's user domain should be similar to ''user_r'' or ''staff_r'', the ''userdom_unpriv_user_template()'' template should be used.
	userdom_unpriv_user_template(myrole)		userdom_unpriv_user_template(myrole)
-	If the role's user domain should be similar to sysadm_r, the userdom_admin_user_template() template should be used.	+	If the role's user domain should be similar to ''sysadm_r'', the ''userdom_admin_user_template()'' template should be used.
	userdom_admin_user_template(myrole)		userdom_admin_user_template(myrole)

JoshuaBrindle: /* Roles Similar to Existing Roles */

2009-11-19T16:12:18Z

Roles Similar to Existing Roles

←Older revision		Revision as of 16:12, 19 November 2009
Line 41:		Line 41:
	userdom_admin_user_template(myrole)		userdom_admin_user_template(myrole)

-	These both will create role myrole_r and user domain myrole_t. Then rules can subsequently be added to myrole_t to customize it.	+	These both will create role ''myrole_r'' and user domain ''myrole_t''. Then rules can subsequently be added to ''myrole_t'' to customize it.

	= Configuring Userland Programs for the New Role =		= Configuring Userland Programs for the New Role =

JoshuaBrindle: /* Default Contexts */

2009-11-19T16:11:46Z

Default Contexts

←Older revision		Revision as of 16:11, 19 November 2009
Line 53:		Line 53:

	== Default Contexts ==		== Default Contexts ==
-	The default_contexts files configure SELinux-aware programs behavior when selecting a context for a user. Typically this is used when logging in, but there are a few other uses.	+	The ''default_contexts'' files configure SELinux-aware programs behavior when selecting a context for a user. Typically this is used when logging in, but there are a few other uses.

-	Add the new role and user domain to services where login is desired. For example, the local_login_t is for local logins, whereas xdm_t is for logins via a X display manager, such as GDM or KDM.	+	Add the new role and user domain to services where login is desired. For example, the ''local_login_t'' is for local logins, whereas ''xdm_t'' is for logins via a X display manager, such as GDM or KDM.

	system_r:local_login_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t		system_r:local_login_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t
Line 62:		Line 62:
	system_r:xdm_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t		system_r:xdm_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t

-	For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed user_r and myrole_r, the default will be user_r:user_t when logging in.	+	For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed ''user_r'' and ''myrole_r'', the default will be ''user_r:user_t'' when logging in.

-	You should notice that '''myrole_r:myrole_t''' was not added to the remote_login_t or sshd_t lines. This means that if a user with only myrole_t tries to log in via login apps running as remote_login_t or sshd_t it will fail.	+	You should notice that ''myrole_r:myrole_t'' was not added to the ''remote_login_t'' or ''sshd_t'' lines. This means that if a user with only ''myrole_t'' tries to log in via login apps running as ''remote_login_t'' or ''sshd_t'' it will fail.

JoshuaBrindle: /* Default Contexts */

2009-11-19T16:10:12Z

Default Contexts

←Older revision		Revision as of 16:10, 19 November 2009
Line 57:		Line 57:
	Add the new role and user domain to services where login is desired. For example, the local_login_t is for local logins, whereas xdm_t is for logins via a X display manager, such as GDM or KDM.		Add the new role and user domain to services where login is desired. For example, the local_login_t is for local logins, whereas xdm_t is for logins via a X display manager, such as GDM or KDM.

-	system_r:local_login_t user_r:user_t myrole_r:myrole_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t	+	system_r:local_login_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t
	system_r:remote_login_t user_r:user_t staff_r:staff_t unconfined_r:unconfined_t		system_r:remote_login_t user_r:user_t staff_r:staff_t unconfined_r:unconfined_t
	system_r:sshd_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t		system_r:sshd_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t
-	system_r:xdm_t user_r:user_t myrole_r:myrole_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t	+	system_r:xdm_t user_r:user_t '''myrole_r:myrole_t''' staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t

	For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed user_r and myrole_r, the default will be user_r:user_t when logging in.		For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed user_r and myrole_r, the default will be user_r:user_t when logging in.
		+
		+	You should notice that '''myrole_r:myrole_t''' was not added to the remote_login_t or sshd_t lines. This means that if a user with only myrole_t tries to log in via login apps running as remote_login_t or sshd_t it will fail.

JoshuaBrindle: /* Default Type */

2009-11-19T16:07:35Z

Default Type

←Older revision		Revision as of 16:07, 19 November 2009
Line 50:		Line 50:
	unconfined_r:unconfined_t		unconfined_r:unconfined_t
	user_r:user_t		user_r:user_t
-	myrole_r:myrole_t	+	'''myrole_r:myrole_t'''

	== Default Contexts ==		== Default Contexts ==

ChrisPeBenito at 12:11, 22 October 2009

2009-10-22T12:11:49Z

←Older revision		Revision as of 12:11, 22 October 2009
Line 41:		Line 41:
	userdom_admin_user_template(myrole)		userdom_admin_user_template(myrole)

-	These both will create role myrole_r and user domain myrole_t.	+	These both will create role myrole_r and user domain myrole_t. Then rules can subsequently be added to myrole_t to customize it.

	= Configuring Userland Programs for the New Role =		= Configuring Userland Programs for the New Role =

ChrisPeBenito: New page: = Roles in Reference Policy = Reference policy consists of several user roles for typical system operation. Rules for each role are contained in individual Reference Policy modules, which...

2009-10-21T15:16:02Z

New page: = Roles in Reference Policy = Reference policy consists of several user roles for typical system operation. Rules for each role are contained in individual Reference Policy modules, which...

New page

= Roles in Reference Policy =
Reference policy consists of several user roles for typical system operation. Rules for each role are contained in individual Reference Policy modules, which allow flexibility in role separation.

{| border="1"
! Role
! Module
!Description
|-
||user_r||unprivuser||Basic user role. This role can do most things a non UID 0 linux user can do.
|-
||staff_r||staff||Administrator's unprivileged user role. This role is basically the same as user_r, but is meant for administrators.
|-
||sysadm_r||sysadm||General system administration role.
|-
||secadm_r||secadm||Security administrator role. Administrates security policy.
|-
||auditadm_r||auditadm||Audit system and audit log administration role. Configures the auditing policy and manages audit logs.
|-
||logadm_r||logadm||Syslog administration role. Configures syslog and manages system logs.
|-
||webadm_r||webadm||Web server administration role. Configures Apache and can optionally manage user web content.
|-
||guest_r||guest||Highly confined user. No X windows support.
|-
||xguest_r||xguest||Highly confined X windows user.
|-
||unconfined_r||unconfined||This role is not confined by SELinux except by memory protections (for example executable memory protections).
|}

This guide will discuss creation of new roles when these roles do not meet needs.

= Creating the Policy for the New Role =
This section of the guide discusses the creation of the policy for the roles. These statements should be added to a policy module. See GettingStarted for more information on creating policy modules.

There are several methods for creating roles in Reference Policy. It is best to use Reference Policy templates, as there are several requirements for a user to log in, but they are beyond the scope of this guide.

== Roles Similar to Existing Roles ==
If the role's user domain should be similar to user_r or staff_r, the userdom_unpriv_user_template() template should be used.
userdom_unpriv_user_template(myrole)
If the role's user domain should be similar to sysadm_r, the userdom_admin_user_template() template should be used.
userdom_admin_user_template(myrole)

These both will create role myrole_r and user domain myrole_t.

= Configuring Userland Programs for the New Role =
== Default Type ==
The default_type file configure SELinux-aware programs behavior when constructing a context. When the program only is provided with a role, the domain for the new context is selected based on this file. Typically this file is only used by the newrole program. Add the new role:domain combination to the end of this file.
sysadm_r:sysadm_t
staff_r:staff_t
unconfined_r:unconfined_t
user_r:user_t
myrole_r:myrole_t

== Default Contexts ==
The default_contexts files configure SELinux-aware programs behavior when selecting a context for a user. Typically this is used when logging in, but there are a few other uses.

Add the new role and user domain to services where login is desired. For example, the local_login_t is for local logins, whereas xdm_t is for logins via a X display manager, such as GDM or KDM.

system_r:local_login_t user_r:user_t myrole_r:myrole_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t
system_r:remote_login_t user_r:user_t staff_r:staff_t unconfined_r:unconfined_t
system_r:sshd_t user_r:user_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t
system_r:xdm_t user_r:user_t myrole_r:myrole_t staff_r:staff_t sysadm_r:sysadm_t unconfined_r:unconfined_t

For each service, the order matters. The service will test to see which role:domain combination is valid for the user logging in, and use the first available choice (left to right). So if the SELinux user is allowed user_r and myrole_r, the default will be user_r:user_t when logging in.