Discussion:
Bug#933858: selinux-policy-default: Selinux default policy does not change context sudo and su from a system administrator (sysadm_u) user account to root
Add Reply
Ramón García
2019-08-04 13:40:01 UTC
Reply
Permalink
Package: selinux-policy-default
Version: 2:2.20190201-2
Severity: important

Dear Maintainer,

First of all, SELinux policy should be more tested. With a default
installation, even without GUI, there are too many activity blocked.

For this report, we create a system administrator user, therefore,
member of the sudoers group, and with the sysadm_u SELinux User.

useradd myname .... -Z sysadm_u

We expect that this user should be able to sudo to root, and after
that the user should be in the
SELinux context unconfied_u:unconfined_r:unconfined_t

But after sudo, the user is still in the same context. Therefore, in
enforced mode, many root commands will fail.

I had to made the following changes in my system to get sudo working

In package sudo, add to /etc/pam.d/sudo add calls to pam_selinux

--------------------------------------------------------------------------------
@@ -1,4 +1,6 @@
#%PAM-1.0
+session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so close
+session [success=ok ignore=ignore module_unknown=ignore default=bad]
pam_selinux.so open

@include common-auth
@include common-accoun
---------------------------------------------------------------------------------


I also created the following SELinux module and add it to policy. The
allow lines should be added to default policy

-------------------------------------------------------------
policy_module(sysadm_custom, 1.0)

require {
role sysadm_r;
role unconfined_r;
type sysadm_t;
type sysadm_sudo_t;
type unconfined_t;
attribute can_change_process_identity;
}

allow sysadm_r unconfined_r;
allow sysadm_sudo_t unconfined_t:process transition;
typeattribute sysadm_sudo_t can_change_process_identity;
--------------------------------------------------------------

Rationale:
- The purpose of sysadm_u/sysadm_r is to specifiy what users are
actually system administrators and should be allowed
to sudo to root.
- when sudo is running from a user with sysadm_u, it is in the context
sysadm_u:sysadm_r:sysadm_sudo_t
- The first allow, is needed so that sudo can change the current role
from sysadm_r to unconfined_r.
- The second, so that it is posible to change from sysadm_sudo_t type
of the instance of sudo executing, to unconfined_t type of the root
user
- The third, so that this sudo instance is able to change process identity.

Similar changes should be allowed to be able to su to root

allow sysadm_su_t unconfined_t:process transition;
typeattribute sysadm_su_t can_change_process_identity;





I also made the following change to
/etc/selinux/default/contexts/default_contexts
But it is likely that it not necessary. (Also included, changes for su to root)

-----------------------------------------------------
--- /etc/selinux/default/contexts/default_contexts.old 2019-07-10
20:40:36.000000000 +0200
+++ /etc/selinux/default/contexts/default_contexts 2019-07-10
23:05:17.000000000 +0200
@@ -10,8 +10,8 @@
staff_r:staff_su_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0
staff_r:staff_sudo_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0

-sysadm_r:sysadm_su_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0
-sysadm_r:sysadm_sudo_t:s0 sysadm_r:sysadm_t:s0
+sysadm_r:sysadm_su_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0 unconfined_r:unconfined_t:s0
+sysadm_r:sysadm_sudo_t:s0 sysadm_r:sysadm_t:s0 unconfined_r:unconfined_t:s0

user_r:user_su_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0
user_r:user_sudo_t:s0 sysadm_r:sysadm_t:s0 user_r:user_t:s0
unconfined_r:unconfined_t:s0
----------------------------------------------------------------------


SELinux is rather difficult to understand and fix issues. I have some
experience with it. Please ask for help if you need.
But please test. A virtual machine with a default configuration should
be able to run with SELInux enforced and no block logged to
/var/log/audit/audit.log


-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages selinux-policy-default depends on:
ii libselinux1 2.8-1+b1
ii libsemanage1 2.8-2
ii libsepol1 2.8-1
ii policycoreutils 2.8-1
ii selinux-utils 2.8-1+b1

Versions of packages selinux-policy-default recommends:
ii checkpolicy 2.8-1
ii setools 4.2.0-1

Versions of packages selinux-policy-default suggests:
pn logcheck <none>
pn syslog-summary <none>

-- Configuration Files:
/etc/selinux/default/contexts/default_contexts changed [not included]
/etc/selinux/default/contexts/users/unconfined_u changed [not included]

-- no debconf information
Dominick Grift
2019-08-05 09:00:01 UTC
Reply
Permalink
This is by design. There is a seperation between confined and unconfined.
sysadm_t is the confined equivalent of the unconfined unconfined_t.

It is true though that sysadm_t (and the policy in general) is incomplete, and that it needs more attention.

You are ofcourse free and encouranged to tailor the policy to your personal requirements.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Ramón García
2019-08-05 22:10:01 UTC
Reply
Permalink
What is the intended purpose of sysadm_t?

If the root user logs in the console, the context is
unconfined_u:unconfined_r:unconfined_t. If some user sudo to root,
that might be allowed or not, but if allowed, shouldn't the session
have the same rights as a root session? Otherwise, what is expected
from sudo is broken.

The same reasoning for su: doing su to root may be allowed or not,
depending on the user. But if allowed, shouldn't the session have the
same unrestricted permissions as a root session?

I believed that the purpose of sysadm_u was to determinate what users
can su/sudo to root+unconfined_t.
Dominick Grift
2019-08-06 07:50:02 UTC
Reply
Permalink
There is some history to all of this. Reference policy is a continuation of the NSA example policy.
The NSA example policy was a "strict" policy that aimed to enforce "least privilege".

Least privilege means that processes only get the permissions they need to do the job.

Much later on after Tresys took over the example policy from NSA and renamed it to reference policy. Red Hat invented the unconfined domain.
The early "targeted" Red Hat policy only had unconfined users (there was no sysadm_u/staff_u etc).

Later on the Fedora targeted policy got merged with Tresys strict reference policy.

The idea was that one could *optionally* allow unconfined domains, confined and unconfined domains *can optionally* live side by side but they werent intended to mingle.
You can make today's "targeted" policy "strict" by disabling the unconfined module.

sysadm is the confined (least privilege) equivalent to unconfined.

In theory that means that sysadm should be able to do pretty much anything that unconfined can do.

The difference between the two is that integrity is enforced in sysadm sessions (least privilege is enforced) where there is no integrity (least privilege) in unconfined sessions.

Enforcing some integrity in a session that should be able to virtually do anything is impossible, so as sysadm_u you will inevitably notice rought edges.
However with work, the situation for sysadm can improve but it will never be perfect.

If you so desire then you can give sysadm_u access to unconfined_r. However this was not the intended design.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Dominick Grift
2019-08-06 11:10:01 UTC
Reply
Permalink
From a traditional strict point of view (without unconfined), this is how the workflow should be:

when you login directly as root you should get "sysadm_r:sysadm_t" (which is the strict equivalent to unconfined)
when you want an unprivileged user (users in the "adm" group) to have root access with sysadm_r:sysadm_t, you would associate that user with staff_u:
useradd -Z staff_u joe
staff_u users should be able to transition to sysadm_r:sysadm_t with sudo:
sudo -r sysadm_r -t sysadm_t -s
or alternatively with newrole/su:
newrole -r sysadm_r
su
unprivileged users that should never have root access should be associated with user_u:
useradd -Z user_u jane
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Ramón García
2019-08-12 11:40:02 UTC
Reply
Permalink
Anyway, the configuration should be consistent.

If we agree that sysadm_u should be the type for system administrator,
when root logins in the console then root should be sysadm_u.

I am not sure if the concept of limited administrator is really
possible. I guess it should be someone who cannot install arbitrary
packages to /usr/bin, but should be able to install packages from
trusted sources or update them; and stop and start services.

But when someone needs a new program, or a custom program, to be
installed? Then one needs a unconfined, fully unrestricted user.

On Tue, Aug 6, 2019 at 12:09 AM Debian Bug Tracking System
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
If you wish to submit further information on this problem, please
to report a problem with the Bug-tracking system.
--
933858: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933858
Debian Bug Tracking System
Loading...