[Pkg-clamav-devel] Lintian override (Was: Re: repo set up)
Stephen Gran
sgran at debian.org
Mon Sep 8 19:05:51 UTC 2008
This one time, at band camp, Michael Meskes said:
> On Mon, Sep 08, 2008 at 12:45:43AM +0100, Stephen Gran wrote:
> > > As you started cleaning out the lintian warnings: We also have a warning about
> > > insecure tmp usage, because of that line in the clamav-base postinst:
> > >
> > > [ -z "$TemporaryDirectory" ] && TemporaryDirectory='/tmp'
>
> The big question is where/how is this used?
Most of the variables in the script wind up as config settings in the
daemon config files.
steve at vancouver:~$ grep TemporaryDirectory /etc/clamav/clamd.conf
/etc/clamav/clamd.conf:TemporaryDirectory /tmp
clamd/clamd.c:
/* set the temporary dir */
if((cpt = cfgopt(copt, "TemporaryDirectory"))->enabled)
cl_settempdir(cpt->strarg, 0);
libclamav/others.c:
void cl_settempdir(const char *dir, short leavetemps) {
char *var;
if(dir) {
var = (char *) cli_malloc(8 + strlen(dir));
sprintf(var, "TMPDIR=%s", dir);
if(!putenv(var))
....
char *cli_gentemp(const char *dir) {
char *name, *tmp;
const char *mdir;
unsigned char salt[16 + 32];
int i;
if(!dir) {
if((mdir = getenv("TMPDIR")) == NULL)
mdir = "/tmp";
} else
mdir = dir;
....
So, effectively, TemporaryDirectory is a way to set the environment
variable TEMPDIR that later calls to the internal `mktemp -d` will use
as a parent directory.
> > Yes, the main problem is that the directory will go away on reboots -
> > that variable is only needed for the config file generation stuff, and
> > not actually used in the script. Telling the various daemons to use
> > directories that disappear out from under them will probably not add
> > robustness :)
>
> It depends. If the directory is only used for volatile stuff, that should be
> fine. I had a look at two servers and there appeared to be no clamav relevant
> file under /tmp at all. So, what uses the TemporaryDirectory?
As above. In theory, all the temporary directories should be cleaned up
after use, so you shouldn't see much there.
> If it is only used by some daemonized software we could create a directory
> belonging to that user and be safe.
It's the parent directory for new directories created on the fly - they
are created and destroyed as needed. Since the relevant process is
creating the directories, the permissions are alrady fine, and it seems
an appropriate use of /tmp to me.
Let me back up a step - what are we fixing? I don't love the
reimplementation of mktemp, but it is an appropriate way to use /tmp,
as far as I can tell. If it's just the lintian complaint, I think that's
either a bug in lintian or a need for an override on our part.
> > ClamAV already uses a (locally written, sigh) mktemp variant for files
> > under /tmp. Probably in this case, a lintian override would be useful,
>
> You mean something like cli_gentempfd? This does not really make it safe:
> http://www.securiteam.com/securitynews/5QP010KN5E.html, although I haven't
> checked whether this is still the same code.
I think we've handled that CVE already, but yes - that's the sort of
thing I'm talking about. It would be really nice if upstream would just
use the off the shelf, working solutions to these sorts of things
instead of reinventing the wheel, but here we are.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran at debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20080908/24e2375a/attachment.pgp
More information about the Pkg-clamav-devel
mailing list