There's a problem with sudo in SELinux which is no big deal -- as long as it gets patched. I know, that's how it always goes.
Without the patch, vulnerability CVE-2017-1000367 sort of wipes out any reason for grappling with SELinux to begin with, and makes the system running it less secure than the relatively less protected server in the next rack running a more vanilla version of Linux. Ironies abound with this vulnerability which was announced last week. Not only does it affect only super-secure SELinux, the sudo command, where the vulnerability actually lies, is meant to tailor and restrict the privileges of those who need more than the capabilities of a normal user, but perhaps less than that of a full blown root user.
In case you don't know, SELinux stands for Security-Enhanced Linux, and is a set of kernel modifications and tools for better securing a Linux system and enforcing access control security policies. In the overall scheme of things, there's not a heck of a lot of servers running it. Many admins automatically turn it off at deployment because it can be difficult getting applications to run properly when using it, and some software vendors actually recommend disabling it in their documentation. But when security is supercritical, SELinux should certainly be running.
This latest vulnerability, in which a sudo user can gain full root access, was discovered by the security firm Qualys and made public early last week on the Openwall open source security list. Not only does the vulnerability only affect SELinux, sudo must be built with SELinux support.
"On an SELinux-enabled system," Qualys said, "if a user is Sudoer for a command that does not grant him full root privileges, he can overwrite any file on the filesystem (including root-owned files) with his command's output, because relabel_tty() (in src/selinux.c) calls open(O_RDWR|O_NONBLOCK) on his tty and dup2()s it to the command's stdin, stdout, and stderr. This allows any Sudoer user to obtain full root privileges."
According to the Sudo website, the bug is found in sudo 1.7.10 through 1.7.10p9 inclusive and sudo 1.8.5 through 1.8.20p1, which means all installations since September, 2012 are affected. Initially, 1.8.20p1 was rushed out the door as a patch for the vulnerability, but was found to offer incomplete protection. Users are now advised to upgrade to Sudo 1.8.20p2.
As long as this gets patched, there's no reason to lose any sleep. Exploitation requires server access by a user with sudo privileges.