Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1251062 > unrolled thread

Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Wolfgang Zarre <lxdev12@zirdeon.com> - 2025-06-25 19:40 +0200
    Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Wolfgang Zarre <lxdev12@zirdeon.com> - 2025-06-25 21:20 +0200
    Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Chris Hofstaedtler <zeha@debian.org> - 2025-06-28 13:00 +0200
    Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Wolfgang Zarre <lxdev12@zirdeon.com> - 2025-06-28 15:10 +0200
    Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Wolfgang Zarre <lxdev12@zirdeon.com> - 2025-07-03 11:00 +0200
      Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host Chris Hofstaedtler <zeha@debian.org> - 2025-07-03 12:40 +0200

#1251062 — Bug#1108311: grml-debootstrap allows to modify ownership in /dev on the host

Package: grml-debootstrap
Version: 0.103
Severity: important

Dear Maintainer,

    * What led up to the situation?
      export DPKG_FORCE="breaks"
      (Just necessary with grml-debootstrap, manually, you have to run dpkg -i
       2 or 3 times to resolve it correctly)
      Bootstrapping Debian 12 with following packages in config/extrapackages/:
        cryptsetup_2%3a2.6.1-4~deb12u2_amd64.deb
        cryptsetup-initramfs_2%3a2.6.1-4~deb12u2_all.deb
        libnss-systemd_254.22-1~bpo12+1_amd64.deb
        libpam-systemd_254.22-1~bpo12+1_amd64.deb
        libsystemd0_254.22-1~bpo12+1_amd64.deb
        libsystemd-shared_254.22-1~bpo12+1_amd64.deb
        libudev1_254.22-1~bpo12+1_amd64.deb
        systemd_254.22-1~bpo12+1_amd64.deb
        systemd-boot-efi_254.22-1~bpo12+1_amd64.deb
        systemd-dev_254.22-1~bpo12+1_all.deb
        systemd-resolved_254.22-1~bpo12+1_amd64.deb
        udev_254.22-1~bpo12+1_amd64.deb

      Relevant groups on the host:
        systemd-resolve:x:104:
        kvm:x:124:

      Relevant groups on the bootstrapped system:
        systemd-resolve:x:997:
        kvm:x:104:

    * What was the outcome of this action?
      Modified ownership on the host in /dev:
        crw-rw---- root systemd-resolve /dev/kvm
        crw-rw---- root systemd-resolve /dev/vhost-net
        crw-rw---- root systemd-resolve /dev/vhost-vsock

    * What outcome did you expect instead?
      An unmodified host system.



The issue was that the package udev was modifying the files in chroot
during the setup and obviously, any package could do that but it should
not modify the host system, which in the worst could crash the host system.

This is caused by mounting rw in line 2016: mount -t devtmpfs udev "${MNTPOINT}"/dev
which allows then in chroot to modify files in /dev.

Therefore it would be good to mount "${MNTPOINT}"/dev read-only, e.g.:
mount -t devtmpfs udev "${MNTPOINT}"/dev -o ro

I also verified the upstream version, which has no change in this
matter.

A test run with "${MNTPOINT}"/dev mounted read-only was successful.


Best regards,
Wolf


-- System Information:
Debian Release: 12.11
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.30+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grml-debootstrap depends on:
ii  cdebootstrap            0.7.8+b31
ii  debian-archive-keyring  2023.3+deb12u2
ii  debootstrap             1.0.141~bpo12+1
ii  e2fsprogs               1.47.2~rc1-2~bpo12+2
ii  fdisk                   2.38.1-5+deb12u3
ii  gawk                    1:5.2.1-2
ii  kmod                    30+20221128-1
ii  util-linux              2.38.1-5+deb12u3

Versions of packages grml-debootstrap recommends:
ii  dialog      1.3-20230209-1
ii  kpartx      0.9.4-3+deb12u1
ii  parted      3.5-3
ii  qemu-utils  1:10.0.0+ds-2~bpo12+2

grml-debootstrap suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1251069

Sorry, I have to correct myself:

> Therefore it would be good to mount "${MNTPOINT}"/dev read-only, e.g.:
> mount -t devtmpfs udev "${MNTPOINT}"/dev -o ro
> 
This does not work, because it will mount /dev on the host read-only as well.

Actually the test was done with:
   mount --bind /dev "${MNTPOINT}"/dev
   mount -o remount,bind,ro "${MNTPOINT}"/dev


Best regards,
Wolf

[toc] | [prev] | [next] | [standalone]

#1251292

Control: tags -1 + upstream
Control: forwarded -1 https://github.com/grml/grml-debootstrap/pull/347

On Wed, Jun 25, 2025 at 05:22:07PM +0000, Wolfgang Zarre wrote:
>     * What was the outcome of this action?
>       Modified ownership on the host in /dev:
>         crw-rw---- root systemd-resolve /dev/kvm
>         crw-rw---- root systemd-resolve /dev/vhost-net
>         crw-rw---- root systemd-resolve /dev/vhost-vsock
> 
>     * What outcome did you expect instead?
>       An unmodified host system.
> 
> 
> 
> The issue was that the package udev was modifying the files in chroot
> during the setup and obviously, any package could do that but it should
> not modify the host system, which in the worst could crash the host system.
> 
> This is caused by mounting rw in line 2016: mount -t devtmpfs udev "${MNTPOINT}"/dev
> which allows then in chroot to modify files in /dev.
> 
> Therefore it would be good to mount "${MNTPOINT}"/dev read-only, e.g.:
> mount -t devtmpfs udev "${MNTPOINT}"/dev -o ro

I tried working on this in https://github.com/grml/grml-debootstrap/pull/347

Unfortunately making the chroot /dev readonly makes resulting VM 
images unbootable. update-grub should put root=UUID=... into 
grub.cfg (as before), but now puts root=/dev/mapper/loop..., which 
cannot work for obvious reasons.

Ideas welcome.

Chris

[toc] | [prev] | [next] | [standalone]

#1251302

On Sat, 28 Jun 2025 12:54:43 +0200 Chris Hofstaedtler <zeha@debian.org> wrote:
> Unfortunately making the chroot /dev readonly makes resulting VM 
> images unbootable. update-grub should put root=UUID=... into 
> grub.cfg (as before), but now puts root=/dev/mapper/loop..., which 
> cannot work for obvious reasons.
> 

Thanks a lot for looking at it and obviously, this is absolutely clear that
root=/dev/mapper/loop.. cannot work.

Maybe I should have mentioned, that I bootstraped with grub disable to a mounted image
file with UKI images for a Secure Boot environment, which can run in VM and on real
hardware.


> Ideas welcome.
> 
I'll have a closer look at this issue next week because I'm really interested in solving
this issue due to the fact that I use grml-debootstrap a lot and maybe sometime in the
future even with a grub loader.

I'll inform you as soon as I have an idea.

Wolf

[toc] | [prev] | [next] | [standalone]

#1251723

On Sat, 28 Jun 2025 12:59:19 +0000 Wolfgang Zarre <lxdev12@zirdeon.com> wrote:
> I'll inform you as soon as I have an idea.
I had a look at it and actually I cannot reproduce root=/dev/mapper/loop.. in grub.cfg,
but maybe I did something wrong or I utilise a different scenario.

Anyway, the following I did which was working flawless and I could start it with qemu
without issues:

Test with grml-debootstrap on Debian 12:
grml-debootstrap version 0.103 with unmodified default configuration

-------------------------------
diff -Nup /usr/sbin/grml-debootstrap.orig /usr/sbin/grml-debootstrap
--- /usr/sbin/grml-debootstrap.orig	2023-02-20 11:40:07.000000000 +0100
+++ /usr/sbin/grml-debootstrap	2025-07-03 09:10:49.906989258 +0200
@@ -2014,6 +2014,7 @@ chrootscript() {
    else
      einfo "Executing chroot-script now"
      mount -t devtmpfs udev "${MNTPOINT}"/dev
+    mount -o remount,bind,ro "${MNTPOINT}"/dev
      mount -t devpts devpts "${MNTPOINT}"/dev/pts
      if [ "$DEBUG" = "true" ] ; then
        chroot "$MNTPOINT" /bin/bash -x /bin/chroot-script ; RC=$?
-------------------------------



# truncate -s 8G test-image-mbr.img
# fdisk -l test-image-mbr.img
Disk test-image-mbr.img: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x11d9d0cb

Device              Boot Start      End  Sectors Size Id Type
test-image-mbr.img1       2048 16777215 16775168   8G 83 Linux

# losetup -P -f test-image-mbr.img
# grml-debootstrap --verbose --password "Have a guess!"  --target /dev/loop0p1 --grub /dev/loop0

Seen on console:
...
Setting up udev (252.38-1~deb12u1) ...
A chroot environment has been detected, udev not started.
fchownat() of /dev/kvm failed: Read-only file system
fchownat() of /dev/vhost-net failed: Read-only file system
fchownat() of /dev/vhost-vsock failed: Read-only file system
...

# mount /dev/loop0p1 mnt
# grep UUID mnt/boot/grub/grub.cfg
	linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro  quiet
		linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro  quiet
		linux	/boot/vmlinuz-6.1.0-37-amd64 root=UUID=e6564375-8c54-4054-a538-b5a95f9627c2 ro single

# umount mnt
# losetup -D
# qemu-system-x86_64 -m 4096 -drive format=raw,file=test-image-mbr.img


Test with grml-debootstrap from master Debian 12:
grml-debootstrap master eae91811116fbc452efe45c6b80ecc647547ea1f

-------------------------------
diff --git a/grml-debootstrap b/grml-debootstrap
index 37893c6..c61e157 100755
--- a/grml-debootstrap
+++ b/grml-debootstrap
@@ -1880,6 +1880,7 @@ chrootscript() {
    else
      einfo "Executing chroot-script now"
      mount -t devtmpfs udev "${MNTPOINT}"/dev
+    mount -o remount,bind,ro "${MNTPOINT}"/dev
      mount -t devpts devpts "${MNTPOINT}"/dev/pts
      if [ "$DEBUG" = "true" ] ; then
        clean_chroot "$MNTPOINT" /bin/bash -x /bin/chroot-script
-------------------------------

# losetup -P -f test-image-mbr.img
# grml-debootstrap --verbose --password "Have a guess!"  --target /dev/loop0p1 --grub /dev/loop0

No message on console!

# mount /dev/loop0p1 mnt
# grep UUID mnt/boot/grub/grub.cfg
	linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro  quiet
		linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro  quiet
		linux	/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=965be905-fb3e-40e3-a738-47e6519b7f50 ro single 
dis_ucode_ldr

# umount mnt
# losetup -D
# qemu-system-x86_64 -m 4096 -drive format=raw,file=test-image-mbr.img

Obviously, this will not cover every scenario, e.g. efi configuration or others, so
please could you let me know which scenario would cause the root=/dev/mapper/loop.. issue.


Cheers,
Wolf

[toc] | [prev] | [next] | [standalone]

#1251729

On Thu, Jul 03, 2025 at 08:53:25AM +0000, Wolfgang Zarre wrote:
> On Sat, 28 Jun 2025 12:59:19 +0000 Wolfgang Zarre <lxdev12@zirdeon.com> wrote:
> > I'll inform you as soon as I have an idea.
> I had a look at it and actually I cannot reproduce root=/dev/mapper/loop.. in grub.cfg,
> but maybe I did something wrong or I utilise a different scenario.
[..]

> Obviously, this will not cover every scenario, e.g. efi configuration or others, so
> please could you let me know which scenario would cause the root=/dev/mapper/loop.. issue.

You can inspect the CI build logs at https://github.com/grml/grml-debootstrap/pull/347

In the meantime we had some discussion in https://github.com/grml/grml-debootstrap/issues/348#issuecomment-3017042208
and further down.

Chris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web