tag 340981 - sarge
clone 340981 -1
reassign -1 genext2fs
severity -1 serious
retitle -1 genext2fs does not preserve file permissions in generated image
merge 338262 338263 -1
reassign 340981 prebaseconfig
close 340981 1.10
Mikko Rapeli wrote:
> 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.
The permissions of the directory in cdebconf-udeb are ok, but those ok
permissions are corrupted by genext2fs during the initrd build process:
joey@dragon:~/src/d-i/installer/build/tmp/netboot/tree>ls -ld var/lib/cdebconf
drwxr-xr-x 2 joey joey 4096 Nov 7 09:56 var/lib/cdebconf/
joey@dragon:~/src/d-i/installer/build/tmp/netboot/tree>genext2fs -d . -b 10000 foo
joey@dragon:~/src/d-i/installer/build/tmp/netboot/tree>sudo mount -o loop foo /mnt
joey@dragon:~/src/d-i/installer/build/tmp/netboot/tree>ls -ld /mnt/var/lib/cdebconf
drwxrwxrwx 2 root root 1024 Dec 31 1969 /mnt/var/lib/cdebconf/
In fact, every directory in this ext2 image is mode 777; every file is
mode 666 (or 777). That is a known genext2fs bug I see, with a recently
filed bug and a patch in the bts, but no other documentation of the
problem. Which could easily be construed as a security hole in its own
right since it leads directly to d-i's class of problem.
I haven't looked outside i386 to see if it affects other arches or not,
but it may well not affect some arches that use cramfs images and so on.
Or it might, if there are similar problems with the tools to generate
those images.
> 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).
It was fixed in prebaseconfig 1.10, the current code just does:
cp /var/lib/cdebconf/questions.dat /var/lib/cdebconf/templates.dat \
$logsavedir/cdebconf
So etch beta 1 is not affected.
> 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.
Surely any user could do the same with the logger command or a small
C program? There may be other theoretical exploit vectors beyond a DOS
though. debconf-get-selections --installer uses these files, for
example.
If the security team wants to follow up on this for stable, it would be
easy to backport the fix. Releasing an advisory would require actually
putting the fixed package into stable (not security.d.o; d-i will not
find it there), as well as rebuilding all the CD images. Any advisory
about this should also include instructions for users who have already
installed (rm -rf /var/log/debian-installer would do, or a command to
fix up the permissions); the directory in the installed system is not
managed by a package in sarge, although we've fixed that since.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature