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? > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
