physical security and data encryption

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
If anyone can pretty much boot in single user mode and change the root
password, that opens up the system and all data to anyone who has
stolen my machine. I know that if physical security is comprosmised,
all bets are off on any OS, but seriously, this is way to easy to break
into. Isn;t there any mechanism to protect the data natively within
Linux distros (specifically Debian/Ubuntu)? Other than installing file
system encryptoin? Thanks.

Re: physical security and data encryption

Hash: RIPEMD160

yusuf wrote:

Quoted text here. Click to load it

AFAIK you need to know the root password to log in to single user mode. But
anyway that doesn't matter. If someone stole your computer he would just get
the harddisk out of it and mount it into his one computer. AFAIK the only
to protect the data on the harddisk from being stolen there is encryption.
You might just want to encrypt some single files with GnuPG though. But I
think the easiest way is to keep your PC safe. If it is just a workstation
you could just remove the hard disk before leaving. There are special hard
disk cases that allow you to easily install and remove the hard disk.
Version: GnuPG v1.4.1 (GNU/Linux)


Re: physical security and data encryption

Matthias Kirchhart wrote:
Quoted text here. Click to load it

One of the best ways to do this transparently, is to set up encrypted
partitions so that the reading and writing of encrypted data is done
without user intervention. At boot, you can set up a script to prompt
you for the pass phrase to "unlock" the encrypted partitions for R/W.

There are multiple ways to do this under Linux, but one that is becoming
increasingly popular and is supported in most mainstream distros with
2.6 series kernels is dm-crypt with LUKS support.

More information is here: / /

and there is a wiki here:

This is what I use under FC4 on a laptop and it is natively supported in
recent versions of Debian/Ubuntu as well. I have set up /home, /tmp and
/var as encrypted partitions using this approach, as well as encrypted
swap space for which there is a slightly different (session specific)

The overhead in terms of disk I/O is minimal on my system which is a 3.2
Ghz P4 with 2GB of RAM and a 7200 RPM 60 Gb HD. This is using 256 bit AES.

I would give serious consideration to this approach. If you decide to go
this route, be sure to read through the documentation and wiki to get a
sense for set up procedures (like pre-writing random data to the HD) and
other operational characteristics.

This way, somebody may get your root password, but if they don't know
the passphrase to your encrypted partitions, they can't read the data.
Same thing if they get physical access to the drive itself.


Marc Schwartz

Re: physical security and data encryption

On Wed, 03 May 2006 23:09:11 +0000, Marc Schwartz wrote:

Quoted text here. Click to load it

I start my machine using grub, which accesses a menu.lst file in
/boot/grub.  Currently I only have one partition for the whole filesystem.
 Do I understand correctly that at least the /boot directory would have to
 be on a partition separate from the encrypted ones?  Where is the
 password to unlock the encryption stored?  How does it get into memory to
 verify the password that you enter?

Thanks for your post.  This should interest a lot of people.

Re: physical security and data encryption

John wrote:
Quoted text here. Click to load it

I do not have / set up as an encrypted partition, as for me, there is no
need. There is nothing there that I need to protect. To encrypt /
requires some additional fiddling with disk boot images and so on. More
pain than it is worth for me.

Yes, the /boot directory would need to be on an unencrypted partition,
possibly unless you would boot the computer with an external drive or a
larger USB memory stick, which I know that some folks do. That will be
dependent upon BIOS support for booting using external devices.

The passwords are stored encrypted in each partition header, where there
are multiple slots for passphrases. This allows you to add new or change
the passphrase without having to re-encrypt the whole partition. You
might want to review the spec document that is available at the LUKS
site above. That will describe the basic process of opening and closing
LUKS partitions and the lower level interactions that take place.

My partitioning approach was based upon:

/home has of course confidential data files, documents, etc.  Having
/home separate also means that I can redo other partitions (or distro
version upgrades) as may be required without messing around with my user
specific stuff.

/tmp can have various temporary files created by programs as needed and
these _may_ contain confidential information at some point.

/var contains a multitude of things, but for me most importantly, I use
fetchmail/postfix/procmail for my inbound e-mail, which means that they
go into /var/spool/mail/*, so that needs to be protected.

swap is protected for obvious reasons.

I have a script set up in /etc/rc.d/rc.local, which is a modification of
the luks-open script on the wiki above. This prompts me at boot for the

There are some distro specific idiosyncrasies relative to
configurations, so my experience on FC may (and will likely) differ than
those on other distros (notably Debian and Gentoo). The wiki I reference
has some good resources for general approaches. Note that the wiki
contains information on dm-crypt plus or minus LUKS as well as setting
up loopback devices and using LVM, so beware the potential for confusion.

One of the coming future enhancements to this whole process will be
tighter integration between dm-crypt/LUKS and HAL (for device mapping),
which should help to make some of these steps more transparent.
Preliminary enhancements have been made in GNOME's mount application
under FC5, but that is just a first step in automating the mounting and
unmounting of LUKS encrypted partitions.

Spend some time reviewing the available documents and the wiki and that
should provide some greater insight.

There is also an e-mail list, which is accessible via Gmane's NNTP
interface at:



Re: physical security and data encryption

Thanks!  I will read the documentation fully.

Re: physical security and data encryption

Quoted text here. Click to load it

I'm curious about this. If you enter the passphrases they are held in ram.
Do they consider the possibility that the passphrases could be written to
the swap partition in the clear? Or does swap get encrypted too?


Re: physical security and data encryption

Llanzlan Klazmon wrote:
Quoted text here. Click to load it

As I noted above and in my first reply, swap is also encrypted, though
using a session specific key generated in /etc/rc.d/rc.local. Thus,
there is no prompt for a password/phrase at boot for swap. I don't need
to know what it is and it is generated randomly at that time.

There is a page on the aforementioned wiki that discusses this:

The one difference for me is that I am using:

   cryptsetup -c aes-cbc-essiv:sha256 -s 256 ...

versus the 64 bit Blowfish configuration that they have listed there.


Marc Schwartz

Re: physical security and data encryption

Matthias Kirchhart wrote:

Quoted text here. Click to load it

I don't understand why no-one has nit picked on this rather grave
misinformation -- you *do not* need to know the root password to
login as root in single user mode (at least in the default configuration
for all the RedHat flavours I've seen -- including up to FC4)

Quoted text here. Click to load it

Aaaahh, that's why no-one nit picked on it!!  :-)

Quoted text here. Click to load it

There are situations where it would be good to prevent the single-
user password-less login -- in a semi-public area, such as a lab
in a College, the machines are physically protected against being
opened (they have locks and stuff that would force the students
to physically break the case to get it open -- but they would not
do that, as it is clear for anyone that we're talking about
vandalism, an unambiguously criminal act).  So, getting physical
access to the hard drive or to resetting the BIOS is not an

If the BIOS setup is password-protected so that they can not
get the computer to boot from a floppy or a CD-ROM, and they
can not get the hard drive, then they really can't do anything
(provided that we assume that they're not willing to physically
violate the machine, given the near-certainty of getting in
serious trouble and possibly face criminal charges).

It would help, and it wouldn't be pointless to prevent single-
user login the way it can be done.


Site Timeline