Re: [Re: Amanda multiple vendor local root compromises]

[oliva () LSD IC UNICAMP BR (Alexandre Oliva)]

On Nov  2, 1999, Robert Watson <robert () cyrus watson org> wrote:

> It should also be pointed out that the symlink bug described in the
> original post seems to be a bug in Amanda that is not platform-specific --
> I haven't seen any further comment on that, only on the package
> installation.

Amanda creates debugging files within /tmp/amanda, by default, and it
will create this directory with permissions so that only the amanda
user will be able to access it (0700).  Both the Amanda user and the
directory for debugging files can be specified at configure time.

I should note, however, that Amanda doesn't check whether the
directories above the specified directory are all safe.  It would be
possible for a malicious user to rename /tmp/amanda, as created by
some Amanda program, if /tmp didn't have the sticky bit set.  It would
be possible for the malicious user to create a new directory with that
name under his/her control, and either deny Amanda access to it,
preventing any debugging output (but no essential functionality would
be denied), or grant it, in order to try (without success :-) to get
Amanda to follow softlinks.

However, because Amanda will first attempt to unlink any debugging
files (without checking for success, which isn't necessary) and then
open them with:

        fd = open(dbfilename, O_WRONLY|O_CREAT|O_EXCL|O_APPEND, 0600);
                                       ^^^^^^^^^^^^^^

it won't open existing files and, in particular, it won't follow
soft-links pointing to existing files.

Anyway, system managers on security-sensitive sites should probably
configure Amanda to use a pre-created debugging directory in a safe
place.  But this needn't be much of a concern, unless /tmp is missing
the sticky bit or it's cleared for some reason and someone is lucky
enough to find a window between a reboot and the first time an Amanda
program is started after it (the directory is never removed by
Amanda).  But as I wrote before, this won't cause any damage to
Amanda, nor will it expose any information about it, since the files
are only readable by the Amanda user itself.

> Has anyone verified that the amanda.debug file is created in such a
> way that a) it has a predictable name

It is actually fixed, unless you enable a configure-time option that
tells Amanda to append the PID to the debugging files, whose purpose
is not of reducing predictability, but rather to allow debugging
output of multiple runs to be retained.

> b) it follows symlinks?

O_CREAT|O_EXCL excludes any possibility of misuse of Amanda to
overwrite sensitive files.  However, if the symlink points to a an
invalid pathname, debugging output may be denied and, if the symlink
points to a non-existing file, it is possible that open will create
it.

> Really, it should probably go in /var/run (or equiv directory on
> whatever OS)

Since Amanda shouldn't run with root privileges, it wouldn't be able
to create files in /var/run.  Of course, you could create
/var/run/amanda, chown/chgrp/chmod it to Amanda and configure it to
use it.

/tmp is probably the best option WRT portability.

> or should be created using mktemp.

That would defeat the whole purpose of creating the debugging files,
which is to allow us to ask users ``what does your
/tmp/amanda/amandad.debug file contain?'' when they ask what's wrong
with their backups :-)

And then, you can always configure --without-debugging.

--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them