--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: initramfs-tools: how do we authenticate initrd images
- From: Ritesh Raj Sarraf <rrs@researchut.com>
- Date: Sat, 07 Feb 2009 01:22:52 +0530
- Message-id: <20090206195252.15231.46376.reportbug@champaran>
Package: initramfs-tools
Version: 0.92o
Severity: wishlist
I always wonder (often late) that why don't I file a bugreport also for
Debian.
Description of problem:
Taken from RH Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=435033
The dependency on initrd is increasing with every release. With features
like
SAN Boot, the OS is heavily dependent on a proper initrd.
Currently, we don't seem to be having a proper way of supporting initrd
images
like we do for other packages (RPM signed packages or non-tainted
kernels)
It is difficult, during root cause of problems reported by customers, to
be sure
that they are running the recommended setup as instructed by the OS
vendor. This
is very true because most 3rd party ISVs or applications
modify/overwrite the
initrd generated under the OS Vendor's guidelines.
We need an infrastructure to track down the correct initrd being used to
boot
the OS.
Version-Release number of selected component (if applicable):
All
How reproducible:
Always
Steps to Reproduce:
1. Tamper some behavior for the initrd.
2. Create the tampered initrd image by overwriting the original initrd
image.
And
1. Boot into the OS.
2. There is no way to know what initrd image was used during boot.
Actual results:
There is no way to identify the authenticity of the initrd image. And
there is
no way to identify what initrd image is used during boot.
Expected results:
We should have a signature based verification of the initrd image (Just
like GPG
signed RPM packages). But how are we going to sign the image during
installtime
creation is a problem.
And we also need a way to identify (on the basis of name) what initrd
image is
used to boot. Something like /proc/cmdline
=============
Above mentioned kind of problems must be the ones why tytso came up with
the
idea of Tainting the kernel from Userspace.
We would not want to spend time debugging, when the user did
unacceptable
things with her OS installation. (Here initrd being the example).
Let me try another minimalistic approach :-)
In the kernel RPM package, during post installation we could generate
the
checksum:
%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
%{expand:%%kernel_variant_posttrans %{?-v*}}\
%{expand:%%post %{?-v*}}\
%{-r:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -r -i -e
's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/'
/etc/sysconfig/kernel || exit $?\
fi}\
/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{KVERREL}%{?-v:.%{-v*}} || exit $?\
# Proposed approach
/sbin/gen-checksum initrd >
/boot/%{KVERREL}%{?-v:.%{-v*}}.initrd.checksum
We add the checksum to /boot or where ever appropriate (inside the
initrd image
?).
During boot, the initrc script in the initrd could do the checksum check
of the
initrd image.
And if the checksum of the initrd image, that we are booting from,
doesn't
tally with the checksum that was generated during kernel installation,
we
*Taint the kernel from Userspace*.
That's all.
Are there other official Red Hat tools that are allowed to mangle with
the
initrd image ? If yes, they also need fall under a similar policy
Now, in our debugging logs, if we see "Tainted U", we know that the user
possibly did something nasty or non-standard.
Do you guys think this approach could help improve the current "Initrd
Dependency" flux?
The bug report is mostly a copy/paste from the RH bugzilla.
For Debian, I'm not sure how we'd want to taclke this.
Do we really care that the user uses the initrd image generated _only_
from post-inst of an official kernel deb package installation ?
Would we be accepting bugs as valid if the initrd was tampered by a 3rd
party ISV ?
Support statement for Debian is different. So I'm not sure if this
problem really applies to Debian or not.
Ritesh
-- Package-specific info:
-- /proc/cmdline
root=/dev/mapper/VgSda2-ROOT ro vga=788 quiet splash
-- /proc/filesystems
ext3
fuseblk
-- lsmod
Module Size Used by
hdaps 9592 1
tp_smapi 19472 0
thinkpad_ec 6776 2 hdaps,tp_smapi
tun 9636 1
michael_mic 2464 6
arc4 1984 6
ecb 2784 6
ieee80211_crypt_tkip 8192 3
radeon 128484 0
drm 77416 1 radeon
rfcomm 31216 0
l2cap 19008 5 rfcomm
bluetooth 48960 4 rfcomm,l2cap
xt_limit 2212 3
xt_state 2208 11
iptable_filter 2784 1
ip_tables 10320 1 iptable_filter
nf_conntrack_ipv4 11980 11
nf_defrag_ipv4 2080 1 nf_conntrack_ipv4
nf_conntrack_ipv6 11768 0
ipv6 234544 19 nf_conntrack_ipv6
nf_conntrack_tftp 4308 0
nf_conntrack_h323 43424 0
nf_conntrack_sip 16116 0
nf_conntrack_irc 5220 0
nf_conntrack_sane 4444 0
nf_conntrack_ftp 6980 0
ts_kmp 2304 5
nf_conntrack_amanda 3872 0
nf_conntrack_proto_udplite 3784 0
nf_conntrack_netbios_ns 2464 0
nf_conntrack_netlink 13888 0
nfnetlink 4504 1 nf_conntrack_netlink
nf_conntrack_proto_dccp 6216 0
acpi_cpufreq 7308 0
nf_conntrack_proto_sctp 7304 0
binfmt_misc 7592 1
nf_conntrack_pptp 5956 0
nf_conntrack_proto_gre 5220 1 nf_conntrack_pptp
cpufreq_conservative 5896 1
cpufreq_ondemand 6572 0
xt_conntrack 3616 0
cpufreq_stats 4036 0
nf_conntrack 57832 18 xt_state,nf_conntrack_ipv4,nf_conntrack_ipv6,nf_conntrack_tftp,nf_conntrack_h323,nf_conntrack_sip,nf_conntrack_irc,nf_conntrack_sane,nf_conntrack_ftp,nf_conntrack_amanda,nf_conntrack_proto_udplite,nf_conntrack_netbios_ns,nf_conntrack_netlink,nf_conntrack_proto_dccp,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,xt_conntrack
freq_table 4448 3 acpi_cpufreq,cpufreq_ondemand,cpufreq_stats
x_tables 13828 4 xt_limit,xt_state,ip_tables,xt_conntrack
cpufreq_powersave 1696 0
cpufreq_userspace 3076 0
fuse 45564 1
loop 13356 0
dm_crypt 11396 0
snd_intel8x0 26588 3
snd_intel8x0m 12716 0
snd_ac97_codec 93700 2 snd_intel8x0,snd_intel8x0m
ac97_bus 1888 1 snd_ac97_codec
snd_pcm_oss 32640 0
snd_mixer_oss 12768 1 snd_pcm_oss
snd_pcm 64740 4 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss
snd_seq_dummy 2788 0
snd_seq_oss 25404 0
joydev 9056 0
pcmcia 31252 0
snd_seq_midi 5856 0
snd_rawmidi 19104 1 snd_seq_midi
snd_seq_midi_event 6624 2 snd_seq_oss,snd_seq_midi
snd_seq 42472 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
irtty_sir 4640 0
serio_raw 5028 0
ipw2200 124424 0
snd_timer 18536 2 snd_pcm,snd_seq
snd_seq_device 6636 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
yenta_socket 21708 1
sir_dev 11364 1 irtty_sir
ieee80211 25864 1 ipw2200
rsrc_nonstatic 9888 1 yenta_socket
psmouse 37200 0
i2c_i801 8336 0
pcspkr 2528 0
ieee80211_crypt 5316 2 ieee80211_crypt_tkip,ieee80211
snd 47160 17 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
pcmcia_core 31316 3 pcmcia,yenta_socket,rsrc_nonstatic
i2c_core 21140 1 i2c_i801
soundcore 6632 1 snd
rng_core 4100 0
snd_page_alloc 8456 3 snd_intel8x0,snd_intel8x0m,snd_pcm
iTCO_wdt 10372 0
nsc_ircc 14480 0
battery 10404 0
ac 4356 0
video 16912 0
output 2944 1 video
parport_pc 22644 0
parport 31412 1 parport_pc
irda 97096 2 sir_dev,nsc_ircc
crc_ccitt 2208 1 irda
thinkpad_acpi 53200 0
intel_agp 22972 0
rfkill 10096 1 thinkpad_acpi
button 6256 0
agpgart 31156 2 drm,intel_agp
led_class 4036 1 thinkpad_acpi
evdev 8580 9
nvram 7500 1 thinkpad_acpi
ext3 108776 2
jbd 50016 1 ext3
mbcache 7588 1 ext3
dm_mirror 12768 0
dm_region_hash 11072 1 dm_mirror
dm_log 8804 2 dm_mirror,dm_region_hash
dm_snapshot 16228 0
dm_mod 47828 9 dm_crypt,dm_mirror,dm_log,dm_snapshot
usbhid 29108 0
hid 35148 1 usbhid
sg 24884 0
sr_mod 13352 0
cdrom 29912 1 sr_mod
sd_mod 28536 3
crc_t10dif 2016 1 sd_mod
ahci 27052 0
ata_generic 4804 0
pata_acpi 4032 0
ata_piix 19492 2
libata 150540 4 ahci,ata_generic,pata_acpi,ata_piix
scsi_mod 136908 4 sg,sr_mod,sd_mod,libata
ide_pci_generic 3812 0
ide_core 96408 1 ide_pci_generic
ehci_hcd 30476 0
uhci_hcd 19888 0
usbcore 125148 4 usbhid,ehci_hcd,uhci_hcd
tg3 91908 0
libphy 19424 1 tg3
thermal 15548 1
processor 40524 3 acpi_cpufreq,thermal
fan 4580 1
thermal_sys 10824 4 video,thermal,processor,fan
-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = update-grub
postrm_hook = update-grub
-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto
-- /etc/crypttab
# <target name> <source device> <key file> <options>
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-custom (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.9-13 GNU cpio -- a program to manage ar
ii findutils 4.4.0-2 utilities for finding files--find,
ii klibc-utils 1.5.12-2 small utilities built with klibc f
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
ii udev 0.125-7 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.10.2-2 Tiny utilities for small and embed
initramfs-tools suggests no packages.
-- no debconf information
--- End Message ---