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. 
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?

  • 1
    I'm voting to close this question as off-topic because it is about a Linux tool and should be asked on Unix & Linux Aug 13, 2018 at 5:57
  • I would think that SELinux config is a better fit on serverfault. (Interesting to start with the premise "I don't trust the sudo / sudoers mechanism, so I want to sandbox it with selinux". Honestly though, I suspect there is lower-hanging fruit in terms of hardening your server that worrying about vulnerabilities in sudo...) Aug 13, 2018 at 14:19

1 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .