1

I can figure out how to map a SELinux user to an existing role, but how do I create new roles? I'm looking to create a restricted admin role for my box.

lairtech
  • 417
  • 7
  • 13
  • Here are some good docs to get you started: http://www.linuxtopia.org/online_books/getting_started_with_SELinux/ – Petter H Aug 22 '13 at 20:21

2 Answers2

2

Use sepolicy from the policycoreutils-devel package on your RedHat distribution. To achieve what you asked you will need to use the following:

sepolicy generate --confined_admin -n NAME [-a ADMIN_DOMAIN] [-u  USER]

This will generate a policy which you can compile (make -f /usr/share/selinux/devel/Makefile) into a module that you can install with semodule -i, but please check the resulting .te file first and adjust it as it fits you. Please also note that the generator insert the permissive domain into the policy by default. Therefore, once you are happy with the created policy -- you need to remove the permissive domain, recompile the policy with make -f /usr/share/selinux/devel/Makefile and off you go :)

galaxy
  • 2,089
  • 2
  • 15
  • 15
0

Unless you want to rewrite pretty much the whole refpolicy, I see no use for a new role. Note that after creating it, you'll need to create custom policy rules for literally every module that role is supposed to be able to use.

My idea of giving a user a restricted administrator role is implemented by:

  1. mapping him/her to guest_u, it is a highly confined (and already existing) SELinux user.
  2. creating Role Based Access Control (RBAC) rules coupled with sudo rules to allow specific people to run specific commands in specific machines under an specific SELinux role and type.
  3. (Of course, this is a limited version of what a really confined environment looks like, you'd need to add, for example, a properly configured rbash, a limited PATH, 2FA authentication, proper authorization, ...)

The key point here is the ability to grant an unprivileged guest_u user the ability to run an elevated privilege command without ever leaving his/her restricted SELinux user mapping.

Check the sudoers(5) manpage for details.

Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Tag_Spec* Cmnd

SELinux_Spec On systems with SELinux support, sudoers entries may optionally have an SELinux role and/or type associated with a command. If a role or type is specified with the command it will override any default values specified in sudoers. A role or type specified on the command line, however, will supersede the values in sudoers.

To check for SELinux support in sudo, run:

# ldd $(which sudo) | grep selinux

On RHEL, sudo has SELinux support enabled by default.

dawud
  • 15,096
  • 3
  • 42
  • 61
  • Well, I personally disagree with this approach since it brings confusion into the system. guest_r roles are documented to have no access to sudo and are restricted. You (making changes to the well documented roles) do more damage than defining a new role based on the documented role instead. It's cheap to create a role and since it's just a policy module it will survive system updates. And, no, you don't need to "rewrite prety much the whole policy" if the policy was properly created and most distros do it right. – galaxy Aug 09 '14 at 14:03
  • It's been a while since I wrote this. I meant, of course, to use staff_u, otherwise a user is not even able to run sudo. (I'll fix it when not on mobile). I do agree with the rest of your comment and your answer, which is better documented and more accurate than mine. – dawud Aug 09 '14 at 14:38