I am trying to block privileges escalations from unprivileged accounts such as ``www-data``.

Basically, if my web server is getting compromised, crackers may find ways to escalate (vulnerabilities found in sudo? root password reuse from another cracked server ?). I want to find a way to forbid this, and I found that putting ``www-data`` into ``user_u`` selinux profile has this effect.

However, looking at the ``audit.log`` file when ``www-data`` tries to ``sudo`` or ``su`` shows this:

For sudo:

    type=AVC msg=audit(1533818833.807:318): avc:  denied  { setuid } for  pid=1417 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability

	Was caused by:
	The boolean selinuxuser_use_ssh_chroot was set incorrectly. 
	Description:
	Allow selinuxuser to use ssh chroot

	Allow access by executing:
	# setsebool -P selinuxuser_use_ssh_chroot 1

For su:

    type=AVC msg=audit(1533818282.076:263): avc:  denied  { write } for  pid=1354 comm="su" name="btmp" dev="dm-0" ino=8428621 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

So, for ``sudo``, it looks like more than a bug (why selinuxuser_use_ssh_chroot ??!) and for ``su``, the deny comes from insufficient rights on ``/var/log/wtmp``

Is this method efficient to block possible escalation from untrusted users ? Or does it look more than a hack ? Is this sufficient to prevent compromised user with root password to get root access?