[Users] A security issue in ovirt 3.2 on fedora - setup leaves a world-writable /etc/sysconfig/nfs

Hi all, The setup code of ovirt releases 3.2 and older set wrong permissions for several files, depending on options chosen during setup/upgrade. The potentially-affected files are: /etc/sysconfig/nfs /etc/sysconfig/iptables /etc/httpd/conf/httpd.conf.BACKUP* /etc/httpd/conf.d/ssl.conf.BACKUP* files under the ISO domain copied there by setup, by default under /var/lib/exports The bug does not affect systems with linux kernels older than 3.1, which included undocumented behavior that prevented it from occurring. Here is a link to the kernel patch that dropped this undocumented behavior: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/comm... In practice this means that among the distributions supported by ovirt, only ovirt on Fedora is affected. ovirt 3.3 is not affected as-is. Systems upgraded from 3.2 might still have the files with wrong permissions, and should follow the actions below. How to fix an existing system? Change the permissions of existing files by running the following commands as root: chmod 600 /etc/sysconfig/nfs chmod 600 /etc/sysconfig/iptables chmod 600 /etc/httpd/conf/httpd.conf.BACKUP* chmod 600 /etc/httpd/conf.d/ssl.conf.BACKUP* find /var/lib/exports -perm /002 -type f -exec chmod 600 {} \; For the last command, replace "/var/lib/exports" with the appropriate directory, if you did not accept the default during setup and configured another directory to hold the ISO domain. A fix for this bug was pushed to gerrit: http://gerrit.ovirt.org/19557 Security implications: This bug allows local users escalate their privileges by editing /etc/sysconfig/nfs and waiting until the nfs service will be started/stopped (e.g. a reboot of the machine). -- Didi