Comment 7 for bug 26336

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 27 Nov 2005 17:28:24 +0200
From: Mikko Rapeli <email address hidden>
To: <email address hidden>
CC: <email address hidden>
Subject: debian-installer and world writable directories

Package: debian-installer
Version: 20051026
Tags: security,sarge

debian-installer in Sarge leaves the directory
/var/log/debian-installer/cdebconf world writable:

# ls -ld `locate debian-installer | grep cdebconf`
drwxrwxrwx 2 root root 4096 Sep 23 17:54
/var/log/debian-installer/cdebconf
-rw-r--r-- 1 root root 49241 Sep 23 18:09
/var/log/debian-installer/cdebconf/questions.dat
-rw-r--r-- 1 root root 3960367 Sep 23 18:09
/var/log/debian-installer/cdebconf/templates.dat

This happens at least when debian-31r0a-i386-binary-1.iso was used to
install Sarge on my two hosts. The root of the problem seems to be two fold:

a) debian-installer root has very permissive directory permissions (ugo=rwx)
b) prebaseconfig's 93save-install-log uses "cp -a" to copy
/var/lib/cdebconf directory to /target/var/log/debian-installer/.

Part a) seems to have gotten some attention in Etch beta 1, but for
reasons beyond my comprehension /var/lib/cdebconf among others is still
world writable. I don't understand the functionality of d-i very well,
but perhaps mkdir is used without a proper umask or -m 0775.

Part b) could be fixed by using a stricter umask or plain cp instead of
'cp -a' in Sarge's 93save-install-log and Etch beta 1's 93save-debconf
( URL:
http://svn.debian.org/wsvn/d-i/trunk/packages/prebaseconfig/prebaseconfig.d/93save-debconf?op=file&rev=28098&sc=0
).

Unfortunately I'm unable get d-i compiled at the moment, so I'm not
shure which specific fix works for shure and wether Etch has the same
problem.

The fact that a subdirectory within /var/log is world writable is a low
risk security issue, since system logs may be DoS'ed by any user filling
up the partition. It also seems to be agains Debian policy 10.8 (
http://www.debian.org/doc/debian-policy/ch-files.html#s10.8 ).

I'm going to study d-i further, but perhaps you developers can already
fix this in the mean time. To me solving part a) is more natural to
Etch, since all d-i processes seem to run as root:root, so other don't
need any permissions on files or directories.

-Mikko