oss-security - ecryptfs-setup-private nitpick

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1723998.qaVZyOmMMY@eee>
Date: Tue, 22 Jul 2014 14:00:03 -0700 (PDT)
From: Raphael Geissert <geissert@...ian.org>
To: Open Source Security <oss-security@...ts.openwall.com>
Subject: ecryptfs-setup-private nitpick

Hi,

Taking a look at ecryptfs-utils 103's ecryptfs-setup-private, there is a bit 
of code that writes the mount pass to a file in /dev/shm hoping to "keep it 
from leaking to the hard-drive":

8<-------->8
        # This will be wrapped by pam_ecryptfs's chauthtok as soon as the 
user
        # chooses a password.  Until that happens (hopefully soon), standard
        # file permissions (600) are all that's protecting it.  Write it to
        # ramdisk, to keep it from leaking to the hard-drive.
        temp=`mktemp /dev/shm/.ecryptfs-XXXXXX`
        printf "%s" "$MOUNTPASS" > "$temp"
        mv -f -T "$temp" "/dev/shm/.ecryptfs-$USER" || error "Could not 
create passphrase file"
8<-------->8

Fastforward to 2014 and /dev/shm is, well, not a ramfs/ramdisk:

/dev/shm -> /run/shm, which is a tmpfs at least on Debian.

And as clearly stated by Documentation/filesystems/tmpfs.txt:
"If you compare it to ramfs (which was the template to create tmpfs)
you gain swapping and limit checking."


So in the hope of avoiding a persistent storage the mount pass is written to 
a file in a tmpfs that can be swapped to... disk.

The file is left on /dev/shm until pam_ecryptfs actually wraps it with the 
login pass.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.