Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Jul 2014 22:37:08 +1000
From: Michael Samuel <mik@...net.net>
To: oss-security@...ts.openwall.com
Subject: Re: ecryptfs-setup-private nitpick

Perhaps I'm wrong, but it appears that at-least on my system encrypted
swap comes up very early in boot - maybe even before the urandom rcS.d
script.

Should urandom be an upstart script which any crypto daemons depend on
(including cryptdisks-udev), rather than rcS.d?

On 23 July 2014 17:23, Dustin Kirkland <kirkland@...ntu.com> wrote:
> On Tue, Jul 22, 2014 at 3:35 PM, Tyler Hicks <tyhicks@...onical.com> wrote:
>> Hi Raphael!
>>
>> On 2014-07-22 14:00:03, Raphael Geissert wrote:
>>> 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.
>>
>> I consider encrypted swap to be a prerequisite to enabling any
>> disk/file encryption solution. Ubuntu sets up encrypted swap when the
>> user selects to encrypt their home directory from the installer.
>>
>> Unfortunately, the ecryptfs-setup-private man page doesn't recommend
>> encrypting your swap but ecryptfs-utils ships a script called
>> ecryptfs-setup-swap that enables encrypted swap.
>
> +1, always encrypt your swap, if you have any respect or concern for
> the privacy of the data on your computer.  We've tried to make it as
> easy as possible to encrypt your swap in Ubuntu and ecryptfs.  The
> documentation could be updated to make this more clear.
>
>> Ignoring the encrypted swap argument, ecryptfs-setup-private shouldn't
>> be storing the plaintext mount passphrase in a manner that is swappable.
>> I think POSIX shared memory segments should provide the persistence and
>> pinnable memory (SHM_LOCKED) needed.
>>
>> Either Dustin (cc'ed) or I will make this improvement. Thanks for the
>> feedback!
>
> Indeed, thanks!
>
>> Tyler
>>
>>>
>>> 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

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ