[Yum] Security issues with include= implementation in yum.conf

[Paul Dickson]

On Sat, 04 Oct 2003 01:35:38 -0400, Ryan Tomayko wrote:

> Some initial work on a patch [1] adding include= functionality to
> yum.conf has been submitted to bugzilla [2] for review and possible
> addition into the 2.1 branch. Some security questions came up in
> discussion with seth and I was hoping to solicit feedback from the list
> on whether anyone thought this to be a significant issue.
> 
> First, includes are recursive. e.g. yum.conf may include a file that
> includes a file that includes a file ad infinitum. And, it is possible
> to include either local files or remote (http/ftp) files. The problem
> here is that it is (currently) possible for a remote file to include any
> other file. When the remote file is managed by the user this isn't a big
> deal but if repositories started providing files for users to include=
> in their yum.conf's, this could lead to security concerns in that the
> remote file can basically set arbitrary values in yum.conf (adding other
> repositories behind the scenes, etc). Or, if a remote file is
> compromised, it could point to some other repository URL without the
> user knowing, which may allow a malicious someone to update almost
> anything (in the absence of gpg).
> 
> Should the responsibility of ensuring included files are "safe" be yum's
> or the user's? I would argue that the user should be responsible but
> that something should be noted in the yum.conf man page about
> discouraging using include on remote files that are not under the direct
> control of the user.

How about putting the config files in their own directory (eg /etc/yum/).
Then, local and remote include= files can only access files within that
directory (no /'s allowed, and no alternate encodings).  The include
directory will be set by command line argument, but defaults to /etc/yum/.
Also, if the config files are saved (never overwritten, perhaps a form of
versioning), the user might be able to trace what happened.

Thinking about this a bit more, how about instead of a user configured
config directory, how about /var/cache/yum/conf/ for holding downloaded
configs (this would allow /etc to be read-only, although why would /etc be
read-only if we're updating RPMs :-).  New changes to a downloaded config
are announced, perhaps with a "diff -u" and there be [main] entries
listing the remote configs that are allow to download other remote configs
(this might eliminate the recursion problem).

As for recursion, save the full pathname (or unique filename) of each
included file along with the number of times it has been included.  These
can adjust these via command line arguments (or [main] values) but there
should be defaults for breadth and depth (possibly 3 and 1, respectively,
for three include files, no recursion).

The values under [main] should not be set or changed by included files.

The only remote config file in yum's shipped rpm should be commented out
with a note mentioning the security implications.  This won't prevent
problems, but at least individual users might read the note and hopefully
think before opening their system. :-)

I hope this message provides some ideas for implementation.

My minds-eye pictures my config file referencing a remote config file of
yum repositories.  Each time there's a change in the remote config file,
yum tells me about it.

	-Paul

Not wishing to be beaten for suggesting gpg signed config files. :-)