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

[Yedidyah Bar David]

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/commit/fs/open.c?id=e57712ebebbb9db7d8dcef216437b3171ddcf115

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