On Nov 2, 1999, Robert Watson <robertat_private> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:09:37 PDT