Just noticed a passing reference to my HTML Renderer in Pure PostScript project in the extended abstract of an interesting scientific paper[1] that focuses on how weaknesses in the PostScript interpreter security model can result in information leakage, compromising the anonymity of document reviewers.
The attack vector follows the notion that the same PostScript document can be rendered differently depending upon information that can be obtained from the interpreter's context; environment variables and contents of the filesystem. Amongst other exploits this raises the possibility of creating a contract that changes after having been electronically signed.
[1] Michael Backes, Markus Durmuth, Dominique Unruh. Information Flow in the Peer-Reviewing Process. In proceedings of IEEE Symposium on Security and Privacy 2007.
Saturday, August 25, 2007
Wednesday, August 22, 2007
Fully Automatic Installation of Debian Etch with Root on LVM using FAI
At work we have been making extensive use of FAI to rapidly deploy Debian hosts. It allows us to take a virgin server and network install a fully functioning Debian system in under four minutes (less than three minutes if you discount the time our hosts spend performing their BIOS tests). It also provides a extensively customisable disaster recovery system into which you can netboot any problematic hosts to investigate and repair them. I thoroughly recommend it to anyone that manages more than a few Debian hosts and that is willing to spend the couple of days or so that it takes to configure and explore all of the options.
Unfortunately for me the current version does not natively support the Linux Logical Volume Management. There are at least two community contributed helper scripts that provide this functionality by means of well-placed hooks provided by FAI, but neither of these have support for root on LVM; in fact one actively discourages it by displaying a warning! Anyhow, placing the root filesystem on LVM is enormously beneficial since amongst other things it allows you to make a consistent point-in-time snapshot of the entire filesystem with no disruption to running services.
In the past, placing root on LVM has indeed been problematic adding extra complexity to the boot process. It requires the bootloader to pass an initial ramdisk to the kernel which contains the necessary modules, libraries, binaries and scripts to discover and enable the Logical Volume that contains the root filesystem, without which the system of no use at all. It must deal with the activation of inactive volumes and handle special volumes such as those under snapshot, mirroring, or even cryptographically secured.
Historically, support for this has been poor due to the old-style initial ramdisks built by Debian Sarge and prior being incapable of dealing with a variety of abnormal conditions, causing the startup scripts within the ramdisk to quietly and uninterruptedly hang with no simple means by which to inspect the state of the locked up system to determine the cause of failure. This periodically rendered unbootable hosts that were not cleanly shut down thus requiring the aid of a live CD distro or netboot disaster recovery image in order to fix the problems. (Usually it would be that the snapshots had failed having ran out of room, requiring that they be first removed in order for the live volume to be made accessible.)
Thankfully this has now all changed because of a vast improvement called initramfs - the new system for creating initial ramdisks in Etch. initramfs has bundled the BusyBox Bash shell clone which is launched if there is any problem in mounting the root filesystem thereby allowing you to repair it without the need for an external recovery system. Together with the big improvements that have made the startup scripts much more robust, this now mostly solves any problems with putting root on LVM. Accordingly, you can take reassurance from the fact that the new Debian Installer provides root on LVM functionality as an installation option for any new Debian system, making it no longer an exceptional setup but a well-trodden path.
Despite not supporting LVM, the FAI system can be easily modified by writing custom hook scripts that are run at designated points during the host installation process. Peter Gervai has created a script to provide support for software RAID and LVM by extending a previous script by Michal Svamberg that provides support for software RAID. The RAID and LVM hook enables the FAI installer to create the necessary LVM entities according to user provided configuration files and it is well documented in on its wiki page.
However there are some steps that must be taken in addition to the setup instructions documented in the wiki in order to successfully FAI build LVM-enabled hosts.
Firstly, ensure that the netboot installer itself is LVM capable by loading device-mapper kernel module before the partitioning task starts:
Simply append dm_mod to the kernelmodules variable in the config file class/20-hwdetect.source in the NFS-exported configuration directory.
Secondly, ensure that the fully installed target system is independantly bootable by recreating the initial ramdisk to have LVM capability and by fixing an erroneous line that finds its way into /etc/fstab due to a minor bug in the FAI partitioning scripts.
Create a new config file called package_config/SW_RAID in the NFS-exported config directory:
lvm-common
lvm2
mdadm
Also create a new config file called scripts/SW_RAID/10-misc:
Those basic changes should be all that is necessary to get any host that is part of the SW_RAID class to FAI install as a root on LVM system. Hopefully we can expect FAI to natively support LVM sometime soon, which will make the process even more painless!
Finally, here are some sample disk configuration files to give you some idea of how easy it should be to maintain.
Sample disk_config/FAIBASE file:
Sample class/SW_RAID.var file:
Unfortunately for me the current version does not natively support the Linux Logical Volume Management. There are at least two community contributed helper scripts that provide this functionality by means of well-placed hooks provided by FAI, but neither of these have support for root on LVM; in fact one actively discourages it by displaying a warning! Anyhow, placing the root filesystem on LVM is enormously beneficial since amongst other things it allows you to make a consistent point-in-time snapshot of the entire filesystem with no disruption to running services.
In the past, placing root on LVM has indeed been problematic adding extra complexity to the boot process. It requires the bootloader to pass an initial ramdisk to the kernel which contains the necessary modules, libraries, binaries and scripts to discover and enable the Logical Volume that contains the root filesystem, without which the system of no use at all. It must deal with the activation of inactive volumes and handle special volumes such as those under snapshot, mirroring, or even cryptographically secured.
Historically, support for this has been poor due to the old-style initial ramdisks built by Debian Sarge and prior being incapable of dealing with a variety of abnormal conditions, causing the startup scripts within the ramdisk to quietly and uninterruptedly hang with no simple means by which to inspect the state of the locked up system to determine the cause of failure. This periodically rendered unbootable hosts that were not cleanly shut down thus requiring the aid of a live CD distro or netboot disaster recovery image in order to fix the problems. (Usually it would be that the snapshots had failed having ran out of room, requiring that they be first removed in order for the live volume to be made accessible.)
Thankfully this has now all changed because of a vast improvement called initramfs - the new system for creating initial ramdisks in Etch. initramfs has bundled the BusyBox Bash shell clone which is launched if there is any problem in mounting the root filesystem thereby allowing you to repair it without the need for an external recovery system. Together with the big improvements that have made the startup scripts much more robust, this now mostly solves any problems with putting root on LVM. Accordingly, you can take reassurance from the fact that the new Debian Installer provides root on LVM functionality as an installation option for any new Debian system, making it no longer an exceptional setup but a well-trodden path.
Despite not supporting LVM, the FAI system can be easily modified by writing custom hook scripts that are run at designated points during the host installation process. Peter Gervai has created a script to provide support for software RAID and LVM by extending a previous script by Michal Svamberg that provides support for software RAID. The RAID and LVM hook enables the FAI installer to create the necessary LVM entities according to user provided configuration files and it is well documented in on its wiki page.
However there are some steps that must be taken in addition to the setup instructions documented in the wiki in order to successfully FAI build LVM-enabled hosts.
Firstly, ensure that the netboot installer itself is LVM capable by loading device-mapper kernel module before the partitioning task starts:
Simply append dm_mod to the kernelmodules variable in the config file class/20-hwdetect.source in the NFS-exported configuration directory.
Secondly, ensure that the fully installed target system is independantly bootable by recreating the initial ramdisk to have LVM capability and by fixing an erroneous line that finds its way into /etc/fstab due to a minor bug in the FAI partitioning scripts.
Create a new config file called package_config/SW_RAID in the NFS-exported config directory:
lvm-common
lvm2
mdadm
Also create a new config file called scripts/SW_RAID/10-misc:
#! /bin/bash error=0 ; trap "error=$((error|1))" ERR cat <<EOF >> $target/etc/initramfs-tools/modules dm_mod dm_mirror dm_snapshot EOF $ROOTCMD update-initramfs -u # Fix the incorrect /dev/ entry that SW_RAID helper makes in fstab sed -ie '/^\/dev\/ /d' /tmp/target/etc/fstab exit $error
Those basic changes should be all that is necessary to get any host that is part of the SW_RAID class to FAI install as a root on LVM system. Hopefully we can expect FAI to natively support LVM sometime soon, which will make the process even more painless!
Finally, here are some sample disk configuration files to give you some idea of how easy it should be to maintain.
Sample disk_config/FAIBASE file:
disk_config disk1 primary /boot 200 rw ; ext2 boot primary swap 2000 rw logical - 1024-
Sample class/SW_RAID.var file:
SW_RAID_CONFIG=" " LVM_VG_CONFIG=" vg00[]=/dev/cciss/c0d0p5 " LVM_LV_CONFIG=" vg00/root[-n root ]=2G:/:ext3: vg00/home[-n home ]=5G:/home:ext3: vg00/srv[-n srv ]=10G:/srv:ext3: vg00/var[-n var ]=5G:/var:ext3: vg00/varlog[-n varlog]=5G:/var/log:ext3: "
Sunday, August 19, 2007
PXE boot FreeDOS with MEMDISK to flash a GIGABYTE BIOS
Having recently sorting through some of the junk that I have been accumulating over the past several years, I decided that I would reincarnate a three-years dormant 1GHz AMD Athlon, which has been almost stripped bare for parts, into a silent running MythTV frontend. After loading the board with a whole 256Mb of RAM, replacing the graphics card with an old NVIDIA GeForce2 MX400, replacing the existing network card with a PXE-capable 3COM 905C Fast EtherLink XL PCI NIC, and salvaging a 40Gb Seagate ST340823A HDD, I was ready to begin.
The task: Install Ubuntu using the Netboot installation image via PXE boot; a process that is usually straightforward and is adequately described in several guides such as this, http://wiki.koeln.ccc.de/index.php/Ubuntu_PXE_Install
The problem: The installer was hanging when attempting to read the partitions on the ST340823A HDD, with the IDE bus being repeatedly reset until it finally gave up. This was no surprise as the CMOS setup utility was freezing whenever I performed an IDE Auto Configuration from within BIOS configuration system, however if it was set to auto detect the drive on boot then things would proceed normally. Hence I assumed (correctly, as it happens) that my current GA-5AA F3 BIOS was restricted to a ~30GB IDE HDD size limit.
New task: Flash a legacy GIGABYTE BIOS on a machine with no external drives and with no MS-DOS boot disks or images to hand; a process that is less simple and not well documented.
GIGABYTE supply an updated BIOS version F7b(Beta) for the board. This comes in the form of a self-extracting executable that can be downloaded from http://www.giga-byte.co.uk/Support/Motherboard/BIOS_Model.aspx?ProductID=1439
The Linux file utility identifies this as an "MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed, RAR self-extracting archive" from which I figured that I could extract the contents using the rar:
The autoexec.bat indicates that you can flash your BIOS from MS-DOS as simply as A:\FLASH830 GA-5AA.F7b
So how do you boot into MS-DOS in order to do this? Cheat! Enter FreeDOS - an open source MS-DOS compatible operating system, which is claimed as being what most motherboard manufacturers now use in the development of their BIOSes. The project provides a raw image of a minimal boot floppy that is available from the file archive at http://www.freedos.org/freedos/files/ called fdboot.img. This needs to be amended to include the flash830.exe and GA-5AA.F7b files which can be done easily from within Linux.
Now all that is required is to boot this image and run the flash commands. MEMDISK, part of the SYSLINUX suite, provides support for booting legacy operating systems and this will work over PXELINUX, http://syslinux.zytor.com
Instructions for configuring PXELINUX are available in several places, but in summary the process involves configuring a DHCP server, configuring a TFTP server, and then copying the necessary boot images and creating the configuration files in the TFTP root.
The required pxelinux.cfg pragma for booting a FreeDOS boot disk image is as follows:
With all of this configured the PC netbooted into FreeDOS from where the flash utility was invoked as A:\FLASH830 GA-5AA.F7b. After reporting success I rebooted the PC and reassuringly the BIOS screen reported the BIOS version as being GA-5AA F7b. And most importantly, the IDE Auto Configuration feature now detected the drive correctly, without freezing!
So I had another go at installing Ubuntu using the Netboot installer... and unfortunately it hung in exactly the same place! Whilst the BIOS update had certainly resolved a particular size limit issue, it had unfortunately not solved the issue with this hard disk.
A bit of Googling revealed that the failure is due to a firmware bug in the Seagate ST340823A model that incorrectly reports the total number of addressable sectors rather than the last addressable sector (zero-based) when queried with the "stroke" feature enabled, http://bugzilla.kernel.org/show_bug.cgi?id=8816
When the Ubuntu partitioner examines the drive it attempts to read the final sector, as reported by the hard disk, which is non-existent and so causes the kernel to throw a fit, repeatedly retrying the read between forced IDE bus resets, until the channel gives up completely.
Unfortunately Seagate do not appear to have released an updated firmware for this drive so it looks like I will miss another opportunity to put FreeDOS to good use ;-)
The task: Install Ubuntu using the Netboot installation image via PXE boot; a process that is usually straightforward and is adequately described in several guides such as this, http://wiki.koeln.ccc.de/index.php/Ubuntu_PXE_Install
The problem: The installer was hanging when attempting to read the partitions on the ST340823A HDD, with the IDE bus being repeatedly reset until it finally gave up. This was no surprise as the CMOS setup utility was freezing whenever I performed an IDE Auto Configuration from within BIOS configuration system, however if it was set to auto detect the drive on boot then things would proceed normally. Hence I assumed (correctly, as it happens) that my current GA-5AA F3 BIOS was restricted to a ~30GB IDE HDD size limit.
New task: Flash a legacy GIGABYTE BIOS on a machine with no external drives and with no MS-DOS boot disks or images to hand; a process that is less simple and not well documented.
GIGABYTE supply an updated BIOS version F7b(Beta) for the board. This comes in the form of a self-extracting executable that can be downloaded from http://www.giga-byte.co.uk/Support/Motherboard/BIOS_Model.aspx?ProductID=1439
The Linux file utility identifies this as an "MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed, RAR self-extracting archive" from which I figured that I could extract the contents using the rar:
$ rar x motherboard_bios_ga-5aa_f7b\(beta\).exe <...snip...> Extracting autoexec.bat OK Extracting flash830.exe OK Extracting GA-5AA.F7b OK All OK
The autoexec.bat indicates that you can flash your BIOS from MS-DOS as simply as A:\FLASH830 GA-5AA.F7b
So how do you boot into MS-DOS in order to do this? Cheat! Enter FreeDOS - an open source MS-DOS compatible operating system, which is claimed as being what most motherboard manufacturers now use in the development of their BIOSes. The project provides a raw image of a minimal boot floppy that is available from the file archive at http://www.freedos.org/freedos/files/ called fdboot.img. This needs to be amended to include the flash830.exe and GA-5AA.F7b files which can be done easily from within Linux.
mount -t vfat -o loop fdboot.img /mnt/floppy cp flash830.exe GA-5AA.F7b /mnt/floppy umount /mnt/floppy
Now all that is required is to boot this image and run the flash commands. MEMDISK, part of the SYSLINUX suite, provides support for booting legacy operating systems and this will work over PXELINUX, http://syslinux.zytor.com
Instructions for configuring PXELINUX are available in several places, but in summary the process involves configuring a DHCP server, configuring a TFTP server, and then copying the necessary boot images and creating the configuration files in the TFTP root.
The required pxelinux.cfg pragma for booting a FreeDOS boot disk image is as follows:
label dos kernel memdisk append initrd=fdboot.img
With all of this configured the PC netbooted into FreeDOS from where the flash utility was invoked as A:\FLASH830 GA-5AA.F7b. After reporting success I rebooted the PC and reassuringly the BIOS screen reported the BIOS version as being GA-5AA F7b. And most importantly, the IDE Auto Configuration feature now detected the drive correctly, without freezing!
So I had another go at installing Ubuntu using the Netboot installer... and unfortunately it hung in exactly the same place! Whilst the BIOS update had certainly resolved a particular size limit issue, it had unfortunately not solved the issue with this hard disk.
A bit of Googling revealed that the failure is due to a firmware bug in the Seagate ST340823A model that incorrectly reports the total number of addressable sectors rather than the last addressable sector (zero-based) when queried with the "stroke" feature enabled, http://bugzilla.kernel.org/show_bug.cgi?id=8816
When the Ubuntu partitioner examines the drive it attempts to read the final sector, as reported by the hard disk, which is non-existent and so causes the kernel to throw a fit, repeatedly retrying the read between forced IDE bus resets, until the channel gives up completely.
Unfortunately Seagate do not appear to have released an updated firmware for this drive so it looks like I will miss another opportunity to put FreeDOS to good use ;-)
Thursday, August 02, 2007
Micro$oft's improved password policy
I'm glad to see that Micro$oft are at last taking security seriously...
"Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords"
http://support.microsoft.com/kb/276304
"Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords"
http://support.microsoft.com/kb/276304
Subscribe to:
Posts (Atom)