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 ?
Many thanks!
