freeipa/doc/workshop/9-selinux-user-map.rst
Francisco Trivino 4af05dde48 Workshop: fix broken Sphinx cross-references.
Many of the workshop pages links are directing to URLs that end with
".rst" instead of ".html", as a result, these links are broken.

This commit introduces explicit targets and references to ensure that
the pages are correctly linked.

Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
2023-09-26 11:30:33 +02:00

144 lines
5.0 KiB
ReStructuredText

.. _9-selinux-user-map:
Unit 9: SELinux User Maps
=========================
**Prerequisites**:
- :ref:`Unit 3: User management and Kerberos authentication <3-user-management>`
- :ref:`Unit 4: Host-based access control (HBAC) <4-hbac>`
- :ref:`Unit 8: Sudo rule management <8-sudorule>`
SELinux is a *mandatory access controls* mechanism for Linux,
providing more powerful and flexible access control than traditional
Unix permissions. Users have an SELinux *context* consisting of a
*user*, *role* and *type*. In this unit, you will cause users
to be *confined* by an SELinux *role-based access control (RBAC)*
policy when the log into hosts that are members of the
``webservers`` Host Group. You will also learn how to change a
user's SELinux context when they execute commands via Sudo.
**Note:** SELinux contexts are applied during PAM-based login, so
when testing our changes in this unit ``su -l <user>`` will not
suffice: it is necessary to log in via SSH. You can do this from
any of the VMs (even ``client`` itself).
Confining users
---------------
Log in as ``alice`` and run ``id -Z`` to see her current SELinux
context::
[alice@client]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
``alice`` is currently *unconfined*. We want her to be confined to
the ``staff_u`` context when she logs in, to limit the impact of an
account compromise.
SELinux User Maps can refer to users and hosts directly, or they can
inherit the users and hosts of an existing HBAC rule. Because
access control is defined by HBAC, it is a good administration
practice to link SELinux User Maps to HBAC rules, so that when users
or hosts are added to the HBAC rule, the correct SELinux context
will automatically be used.
Recall that members of the ``sysadmin`` User Group already have
access to ``webservers`` via the ``sysadmin_webservers`` rule that
was created in :ref:`Unit 4: Host-based access control (HBAC)<4-hbac>`. Create
the SELinux User Map::
[client]$ ipa selinuxusermap-add sysadmin_staff_t \
--hbacrule sysadmin_webservers --selinuxuser staff_u:s0-s0:c0.c1023
-----------------------------------------
Added SELinux User Map "sysadmin_staff_t"
-----------------------------------------
Rule name: sysadmin_staff_t
SELinux User: staff_u:s0-s0:c0.c1023
HBAC Rule: sysadmin_webservers
Enabled: TRUE
Now login in as ``alice`` over SSH and observe that she is confined
by the ``staff_u`` policy::
[server]$ ssh alice@client.ipademo.local
alice@client.ipademo.local's password:
Last login: Fri Sep 2 05:47:03 2016
[alice@client]$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
**Note:** in production use you should ensure that only one HBAC
rule allows access for a given user/host/SELinux User Map
combination. Only one SELinux policy will be applied, and if
multiple policies match, the winning policy may be chosen
inconsistently.
Unconfined ``sudo``
-------------------
``alice`` is now confined by the ``staff_u`` policy, but being a
``sysadmin`` she needs to be unconfined when running commands via
``sudo``. With the current configuration, commands run via ``sudo``
inherit a user's context, as the following commands demonstrate::
[alice@client]$ sudo -s
[sudo] password for alice:
sh-4.4# id
uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
sh-4.4# echo "Hello, world!" > /etc/motd
sh: /etc/motd: Permission denied
As you can see, ``alice`` became ``root``, but the SELinux
confinement prevents her from writing ``/etc/motd`` (and many other
things). Let's make it so that ``alice`` can do her job. We need
to update the Sudo rule to change the SELinux context::
[alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption type=unconfined_t
-------------------------------------------------------------
Added option "type=unconfined_t" to Sudo Rule "sysadmin_sudo"
-------------------------------------------------------------
Rule name: sysadmin_sudo
Enabled: TRUE
Host category: all
Command category: all
RunAs User category: all
RunAs Group category: all
Sudo Option: type=unconfined_t
[alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption role=unconfined_r
-------------------------------------------------------------
Added option "role=unconfined_r" to Sudo Rule "sysadmin_sudo"
-------------------------------------------------------------
Rule name: sysadmin_sudo
Enabled: TRUE
Host category: all
Command category: all
RunAs User category: all
RunAs Group category: all
Sudo Option: type=unconfined_t, role=unconfined_r
Now when ``alice`` runs ``sudo`` it changes the SELinux context of
the program being run::
[alice@client]$ sudo -s
sh-4.4# id -Z
staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh-4.4# echo "Hello, world!" > /etc/motd
sh-4.4# cat /etc/motd
Hello, world!
This concludes the unit. You can now proceed to
:ref:`Unit 10: SSH user and host key management <10-ssh-key-management>`
or
:ref:`return to the curriculum overview <curriculum-overview>`
to see all the available topics.