selinux : blocking sudo and su usage by placing user into user_t profile

Question

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?

Answer 1

The message about selinux_use_ssh_chroot boolean is a diagnostic suggestion based on the generated AVC denial message. The exact denial is for setuid capability and the boolean in question would enable a rule allowing the operation, hence it was automatically suggested. Similarly an automatic suggesting for additional rule allowing access was generated when you attempted to use su. AVC denial messages are to be expected if you attempt to gain privileges as confined user.

However, your testing doesn't reflect how web server (apache or nginx) would behave in confined domain. By default, it should run in confined httpd_t domain. If there isn't a targeted policy in place, the service will run in unconfined domain, not in user_t.

If a confined web server is compromised, the attacker is still confined httpd_t domain and can't gain any new permissions that weren't originally allowed. There shouldn't be any rules allowing a process in httpd_t to execute sudo/su. Even if the process should manage to chuid to root, without any transition rules to another domain the process would still stay in httpd_t and be restricted to the rules for httpd_t.