I was planning to set up my laptop from scratch for a while now... so I did.
MD5SUMS and MD5SUMS.sign files:
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/MD5SUMS.sign
gpg --verify MD5SUMS.sign, which will fail but tell you the signing key ID (88C7C1F7 in this case). Get the key and re-run the verification: gpg --recv-key --keyserver subkeys.pgp.net 88C7C1F7 && gpg --verify MD5SUMS.sign. The output should now say "Good signature from [...]".
md5sum -c MD5SUMS. The output should contain debian-testing-i386-binary-1.iso: OK.wodim debian-testing-i386-binary-1.iso./boot (ext3) as primary partition, and make the rest of the hard drive one huge partition which has "Use as:" set to "physical volume for encryption"./boot reside on a dm-crypt device)! Never set up unencrypted swap!/root and /home/uwe. Log out and log in again to make ~/.bashrc and ~/.inputrc take effect.mkdir /etc/rc.boot && cp fw_laptop /etc/rc.boot && chmod 700 /etc/rc.boot/fw_laptop && sh /etc/rc.boot/fw_laptop/etc/init.d/foo stop.chmod 700 /root /home/uwe./etc/passwd: give all users except for root, sync, uucp and your user account /usr/sbin/nologin as login shell. None of these accounts really needs a valid login shell (nologin will log any login attempts for those accounts)./etc/group: remove your user account from the dialout, cdrom, and floppy group. The groups audio, video, and plugdev can stay./etc/fstab: add some mount options such as ro, nosuid, noexec, or nodev as you see fit. Example:/dev/mapper/vg--whole-lv--root / ext3 defaults,errors=remount-ro 0 0 /dev/sda2 /boot ext3 defaults,nodev,nosuid,noexec,ro 0 0 /dev/mapper/vg--whole-lv--home /home ext3 defaults,nodev,nosuid 0 0 /dev/mapper/vg--whole-lv--tmp /tmp ext3 defaults,nodev,nosuid 0 0 /dev/mapper/vg--whole-lv--usr /usr ext3 defaults,nodev,ro 0 0 /dev/mapper/vg--whole-lv--var /var ext3 defaults,nodev 0 0 /dev/mapper/vg--whole-lv--swap none swap sw 0 0 /dev/scd0 /media/cdrom iso9660 noauto,nodev,nosuid,noexec,uid=uwe,gid=uwe 0 0
ro) file systems, configure Apt so that it can remount them read-write when installing/removing packages. Add this to /etc/apt/apt.conf:
DPkg
{
Pre-Invoke { "mount -o remount,rw /usr; mount -o remount,rw /boot"; }
Post-Invoke { "mount -o remount,ro /usr; mount -o remount,ro /boot"; }
}
password foo" line (which contains the GRUB password in plain-text) from your /boot/grub/menu.lst with a "password --md5 $1$1234567890..." line, where the MD5 hash ($1$1234567890...) can be generated with grub-md5-crypt. Additionally, add such a password line after each "title" line in the GRUB config-file, so that nobody can boot any OS installed on the laptop without a password!/etc/network/interfaces:auto eth0 iface eth0 inet dhcp pre-up /etc/rc.boot/fw_laptop
Run /etc/init.d/networking restart. The firewall script will run every time the network is started.
/etc/apt/sources.list:
deb http://ftp.de.debian.org/debian unstable main
deb-src http://ftp.de.debian.org/debian unstable main
apt-get update && apt-get dist-upgrade. All packages are GnuPG-signed and will be verified by Apt. The installer already ships the required key (for 2006), so everything should just work. Still, you should read about SecureApt.sysv-rc-conf to disable all daemons you don't want to start per default: sysv-rc-conf foo off.apt-get install samhain. You want to be notified if your system files are being tampered with (e.g. replaced by a rootkit).Now install and set up SELinux. This section is based on notes from Erich Schubert (thanks!), and will soon appear in the SELinuxSetup wiki page, too.
apt-get install selinux-basics selinux-policy-refpolicy-targeted./boot/grub/menu.lst and add selinux=1 to your kernel command line to enable SELinux upon booting./etc/pam.d/login uncomment the "session required pam_selinux.so multiple" line. Do the same in /etc/pam.d/ssh if you have ssh installed./etc/default/rcS set FSCKFIX=yes./etc/init.d/bootmisc.sh search for "Update motd" and comment the two lines below that line. Then rm /var/run/motd.n" in /etc/postfix/master.cf and execute echo 'SYNC_CHROOT="n" >> /etc/default/postfix').check-selinux-installation to check for common SELinux problems on Debian (such as the above mentioned).touch /.autorelabel. Reboot. touch /.autorelabel (again). Reboot (again).setenforce 1 or by adding enforcing=1 to the kernel command line in /boot/grub/menu.lst./boot partition is still unencrypted, so an attacker can tamper with it. Boot from a CD-R, forbid booting from hard drive (BIOS). Sign/mark the CD-R physically, so you'll know when someone replaced your CD-R with his own, back-doored one.qemu -snapshot -net none foo.img.That's it. You can take off that stupid tin-foil hat now.
Update 2006-09-29: Fixed typos. Mentioned sxid. Added two-factor authentication.
This is old news by now, but still interesting IMHO. Jonathan Brossard has posted an article on BugTraq which gives a pretty good introduction to the inner workings of the BIOS (with lots of links to more detailed resources) as well as known vulnerabilities of the BIOS password mechanism.
The most interesting part is when he explains that the BIOS doesn't seem to erase its own keyboard buffer before it hands over control to the operating system. Also, current OSes (Linux, Windows, *BSD, etc.) don't seem to clear that buffer either.
This may not sound dangerous, but it actually allows anyone who can read the contents of your RAM, starting from address 0x041e, to view the keyboard buffer contents. And this buffer contains the BIOS password you type in when booting your machine (if you set/use a BIOS password, of course).
This one-liner (executed as root) should let you view your password as plain text:
dd if=/dev/mem bs=512 skip=2 count=1 | hexdump -C | head
(Only every second character belongs to the password, the rest are key scan codes, I think).
I also noticed that this same buffer also contains your LILO password, too! The same is probably true for passwords of other boot loaders such as GRUB, but I didn't test that.
Yes, reading this part of the RAM usually requires root privileges in Unix-like OSes, but as the security problem is OS-independant other OSes (e.g. DOS, or older Windows versions) might be directly affected.
But even on more secure OSes this plain-text storage of the BIOS/boot loader passwords might be a problem. Combine this with some Firewire insecurities and attackers with physical access to your machine (e.g. your unattended laptop, while you are on the toilet) might be able to read your BIOS/LILO passwords even though you locked your machine. I haven't yet tried this, but I'm pretty sure it's possible. Please post the results here if you try this.
(via Stefan 'Sec' Zehl)
Update 2006-01-09: It seems that when you use software suspend (swsuspend2) the RAM area can/will also contain your root password! Thanks nelson for reporting.
Recent comments
21 weeks 3 days ago
47 weeks 4 days ago
1 year 3 weeks ago
1 year 3 weeks ago
1 year 3 weeks ago