Roles and Users Security Policy Development Primer for Security Enhanced Linux (Module 8)

Transcription

1 Roles and Users Security Policy Development Primer for Security Enhanced Linux (Module 8)

2 2 Role-based Access Control Model Traditional RBAC policy assigns privileges and authorizations to roles authorizes users for one or more roles SE Linux RBAC model assigns privileges and authorizations to domain types assigns domain types to roles authorizes user for one or more roles also supports a role hierarchy concept

3 3 Role Identifier in Security Context root:sysadm_r:sysadm_t role identifier Role identifier in every security context For subjects, represents current role For objects, role is typically object_r role unused for objects

4 4 Role Declaration Statement role role_identifier types type_list ; role_identifier: role name separate name space from types convention: end with _r type_list: one or more assigned types `* and `~ may be used attributes may be used multiple types/attributes enclosed in braces `{ } only domain types makes sense Multiple role statements for same identifier allowed role will contain the union of all assigned types this technique is commonly used in sample policy Only assigned types may be in security context with role

5 5 Roles in Domain Transitions user_r:passwd_t write, setattr, (change password) login fork() passwd user_r:user_t execve() r root root bash r-s--x--x root root shadow_t /etc/shadow passwd_exec_t role user_r types passwd_t; type_transition user_t passwd_exec_t : process passwd_t; /usr/bin/passwd allow user_t passwd_exec_t : file { getattr execute };

6 6 Role Allow Statement Syntax allow current_roles new_roles ; may use `*, `~, and sets of roles Allows current role to transition to new roles Of limited use in current policy most roles can transition to others constraints are used to restrict role changes to be discussed

7 7 Other Role Statements Role Dominance Roles can be defined as dominate of other roles can be defined solely this way Roles inherits all the types of roles it dominates example: dominance {role foo_r {role sysadm_r ; role user_r; } } defines foo_r and has it inherit all the types of sysadm_r and user_r Not used in sample policy Role Transition (deprecated) changes role based on current process role and file type syntax: role_transition current_roles types new_role type transition preferred method for changing process privilege newrole program method for user to change role

8 8 User Identity Model Standard Linux user identifiers changed primarily for purposes of privilege change not necessarily because user changed can change arbitrarily by root SE Linux user identity orthogonal to Linux user identifiers ability to change user is controlled by policy Linux and SE Linux need not be same allows for generic user identity where user not important

9 9 User Identifier in Security Context root:sysadm_r:sysadm_t user identifier User identity defines allowed roles for context no user allow or transition rules Unrelated to Linux UIDs Login programs (login, sshd, etc.) determine initial user identity constraints prevent change otherwise

10 10 User Declaration Statement user user_identifier roles role_list ; user_identifier: user identity separate name space from roles, type, and Linux users role_list: one or more assigned roles multiple roles enclosed in braces `{ } Only roles authorized for user identity may be in security context means by which roles are associated with user Examples (see./policy/users) user root { user_r sysadm_r } ; user jane user_r;

11 11 Special User Identifiers system_u user identity for system processes and resources never create a system_u Linux user never remove the system_u identity from policy user_u optional, need not exist if defined, used for all Linux users not defined to policy if not defined, undefined Linux users can t login WARNING: careful if user_u used adding any new user will assume user_u identify do not include if you wish only explicitly defined users

12 12 Determining Context on Login login, sshd, and crond all set security context at login Pre-Oct 2002, two files determined default login context /etc/security/default_context (login, sshd) /etc/security/crond_context (crond) user must have entry for login to succeed context must be valid too Post-Oct 2002, different method method for determining user default context changed $HOME/.default_contexts (user-specific defaults) /etc/security/default_contexts (system defaults) context must still be valid (but a default will also be chosen)

13 13 New Default Contexts login determines valid user context via libsecure test with selinux/libsecure/test/get_user_sids./get_user_sids system_u:system_r:local_login_t root./get_user_sids system_u:system_r:crond_t root Determined via default_contexts file system_r:local_login_t user_r:user_t system_r:sshd_t user_r:user_t system_r:crond_t user_r:user_crond_t system_r:system_crond_t first column identifies login process s partial context second column defines ordered set of default contexts first context allowed for user selected

14 14 Some user management tools passwd utility wrappers spasswd: checks SE Linux user ID before allowing sadminpasswd: allows privileged domain change all suseradd, suserdel, svipw, schfn seuser manages users in policy does not handle defining Linux users to system handle old and new default contexts command line and graphical

15 15 QUESTIONS?