• Securely erase files cached in memory (dm_crypt)

    From bmearns@110:300/1.1 to All on Sun Jan 8 17:53:40 2012
    I'm setting up a dm_crypt/LUKS volume and I want to make sure that
    when the volume is suspended/closed, all the decrypted data is
    securely removed from memory.

    If I understand dm_crypt correctly, all data on the harddisk is
    encrypted, but pages will be decrypted into RAM on demand. The manpage
    for cryptsetup specifies that luksSuspend wipes the encryption key
    from the kernel, but doesn't say anything about data that's already
    been decrypted. Is this all taken care of by dm_crypt, or do I need to
    be proactive about removing it, and if so, how? Also, do I need to
    worry about decrypte blocks being put in swap space?

    Thanks,
    -Brian

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: http://groups.google.com (110:300/1.1@linuxnet)
  • From Richard Kettlewell@110:300/1.1 to All on Mon Jan 9 12:02:11 2012
    bmearns <mearns.b@gmail.com> writes:
    I'm setting up a dm_crypt/LUKS volume and I want to make sure that
    when the volume is suspended/closed, all the decrypted data is
    securely removed from memory.

    If I understand dm_crypt correctly, all data on the harddisk is
    encrypted, but pages will be decrypted into RAM on demand. The manpage
    for cryptsetup specifies that luksSuspend wipes the encryption key
    from the kernel, but doesn't say anything about data that's already
    been decrypted. Is this all taken care of by dm_crypt, or do I need to
    be proactive about removing it, and if so, how?

    I can't see anything in the kernel or the tools that would erase cached decrypted data, but I may not be looking in the right places.

    Also, do I need to worry about decrypte blocks being put in swap
    space?

    I think you're OK on this one; AFAIK the buffer cache is not swapped.
    (It's hard to see what the point of doing so would be.)

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: Anjou (110:300/1.1@linuxnet)
  • From bmearns@110:300/1.1 to All on Tue Jan 10 04:04:06 2012
    On Jan 9, 6:02=A0am, Richard Kettlewell <r...@greenend.org.uk> wrote:
    bmearns <mearn...@gmail.com> writes:
    I'm setting up a dm_crypt/LUKS volume and I want to make sure that
    when the volume is suspended/closed, all the decrypted data is
    securely removed from memory.

    If I understand dm_crypt correctly, all data on the harddisk is
    encrypted, but pages will be decrypted into RAM on demand. The manpage
    for cryptsetup specifies that luksSuspend wipes the encryption key
    from the kernel, but doesn't say anything about data that's already
    been decrypted. Is this all taken care of by dm_crypt, or do I need to
    be proactive about removing it, and if so, how?

    I can't see anything in the kernel or the tools that would erase cached decrypted data, but I may not be looking in the right places.

    Also, do I need to worry about decrypte blocks being put in swap
    space?

    I think you're OK on this one; AFAIK the buffer cache is not swapped.
    (It's hard to see what the point of doing so would be.)

    --http://www.greenend.org.uk/rjk/

    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by
    swapping.

    So now I just have to worry about anything cached in RAM, which is a
    bummer, because the whole point of this is to purge all the data
    without having to power cycle.

    -Brian

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: http://groups.google.com (110:300/1.1@linuxnet)
  • From William Colls@1:0/0 to All on Tue Jan 10 04:47:34 2012
    On 01/09/2012 10:04 PM, bmearns wrote:
    On Jan 9, 6:02 am, Richard Kettlewell<r...@greenend.org.uk> wrote:
    bmearns<mearn...@gmail.com> writes:
    I'm setting up a dm_crypt/LUKS volume and I want to make sure that
    when the volume is suspended/closed, all the decrypted data is
    securely removed from memory.

    If I understand dm_crypt correctly, all data on the harddisk is
    encrypted, but pages will be decrypted into RAM on demand. The manpage
    for cryptsetup specifies that luksSuspend wipes the encryption key
    from the kernel, but doesn't say anything about data that's already
    been decrypted. Is this all taken care of by dm_crypt, or do I need to
    be proactive about removing it, and if so, how?

    I can't see anything in the kernel or the tools that would erase cached
    decrypted data, but I may not be looking in the right places.

    Also, do I need to worry about decrypte blocks being put in swap
    space?

    I think you're OK on this one; AFAIK the buffer cache is not swapped.
    (It's hard to see what the point of doing so would be.)

    --http://www.greenend.org.uk/rjk/

    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by
    swapping.

    So now I just have to worry about anything cached in RAM, which is a
    bummer, because the whole point of this is to purge all the data
    without having to power cycle.

    -Brian

    I'm no expert in this, but it would seem to me, that once the program is suspended, and the key removed, the program would also de-allocate any
    memory it is holding, and on any kind of reasonably busy machine, that
    memory is going to be fairly quickly re-allocted to something else and
    over written. But I'm really just guessing.

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: National Capital Freenet, Ottawa, Ontario, Ca
  • From bmearns@110:300/1.1 to All on Wed Jan 11 22:51:39 2012
    On Jan 9, 10:47=A0pm, William Colls <william.co...@rogers.com> wrote:
    On 01/09/2012 10:04 PM, bmearns wrote:
    [snip]
    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by swapping.

    So now I just have to worry about anything cached in RAM, which is a bummer, because the whole point of this is to purge all the data
    without having to power cycle.

    -Brian

    I'm no expert in this, but it would seem to me, that once the program is suspended, and the key removed, the program would also de-allocate any
    memory it is holding, and on any kind of reasonably busy machine, that
    memory is going to be fairly quickly re-allocted to something else and
    over written. But I'm really just guessing.

    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices. If I just use malloc to keep grabbing
    memory until the call fails, that should work, right? It will page
    anything it needs to keep, but those deallocated blocks of decrypted
    data should be fair game.

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: http://groups.google.com (110:300/1.1@linuxnet)
  • From Richard Kettlewell@110:300/1.1 to All on Wed Jan 11 23:09:41 2012
    bmearns <mearns.b@gmail.com> writes:
    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices.

    Or even longer if the machine _isn't_ busy. And presumably you want to
    be able to walk away within minutes reasonably confident that your data
    is no longer on that machine.

    If I just use malloc to keep grabbing memory until the call fails,
    that should work, right? It will page anything it needs to keep, but
    those deallocated blocks of decrypted data should be fair game.

    You are likely to find the OOM killer start terminating things before
    malloc() fails.

    If there's more on the (unencrypted l-) disk that you have RAM then
    catting it all to /dev/null might do the job. It still doesn't seem
    very certain though.

    I must say, though, I'm not entirely convinced there's a watertight use
    case here; if you don't trust the machine after you leave it, why do you
    trust it before you started?

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: Anjou (110:300/1.1@linuxnet)
  • From bmearns@110:300/1.1 to All on Wed Jan 11 23:23:33 2012
    On Jan 11, 5:09=A0pm, Richard Kettlewell <r...@greenend.org.uk> wrote:
    bmearns <mearn...@gmail.com> writes:
    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices.

    Or even longer if the machine _isn't_ busy. =A0And presumably you want to
    be able to walk away within minutes reasonably confident that your data
    is no longer on that machine.

    If I just use malloc to keep grabbing memory until the call fails,
    that should work, right? It will page anything it needs to keep, but
    those deallocated blocks of decrypted data should be fair game.

    You are likely to find the OOM killer start terminating things before malloc() fails.

    If there's more on the (unencrypted l-) disk that you have RAM then
    catting it all to /dev/null might do the job. =A0It still doesn't seem
    very certain though.

    I must say, though, I'm not entirely convinced there's a watertight use
    case here; if you don't trust the machine after you leave it, why do you trust it before you started?

    --http://www.greenend.org.uk/rjk/

    Mind you this is all strictly hyper-paranoid stuff, I have no actual
    need for anything this secure, I'm just trying to pin down all the
    loose corners. It'd be stupid to setup a secure system, necessary or
    not, and end up having some gaping holes in it.

    It's not an issue of trusting the machine, but the other people who
    have access to it, specifically people who come along after (not so
    much before: if they've already been there, then there's probably a
    lot of other stuff to worry about). The vague use case I'm thinking of
    is "authorities" busting the door down, and doing a cold boot attack
    to read back everything from memory. In particular, the specific
    situation I'm working on here has a one-time use random key generated
    when the volume is setup, that the user never sees, so fifteen-dollar-
    wrench attacks are not an issue (at least not in terms of reading data
    off the disk).

    -Brian

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: http://groups.google.com (110:300/1.1@linuxnet)
  • From unruh@1:0/0 to All on Thu Jan 12 02:54:22 2012
    On 2012-01-11, bmearns <mearns.b@gmail.com> wrote:
    On Jan 9, 10:47?pm, William Colls <william.co...@rogers.com> wrote:
    On 01/09/2012 10:04 PM, bmearns wrote:
    [snip]
    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by
    swapping.

    No It has no idea that the data it has in memory is the same as the data
    on disk. After all programs often change data in the course of their exectution. In fact that is usually the whole purpose of programs.
    Once a program reads data from disk into memory, that data is different
    from the data on the disk, and it had better get chached AND swapped.


    So now I just have to worry about anything cached in RAM, which is a
    bummer, because the whole point of this is to purge all the data
    without having to power cycle.

    -Brian

    I'm no expert in this, but it would seem to me, that once the program is
    suspended, and the key removed, the program would also de-allocate any
    memory it is holding, and on any kind of reasonably busy machine, that
    memory is going to be fairly quickly re-allocted to something else and
    over written. But I'm really just guessing.

    Why would it deallocate its memory if it is just suspended? You could
    restart it. DO you mean if the program is stopped?
    Then yes, the memory will get dumped back to theheap, or the stack.
    But it is not erased.



    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices. If I just use malloc to keep grabbing
    memory until the call fails, that should work, right? It will page
    anything it needs to keep, but those deallocated blocks of decrypted
    data should be fair game.

    No. programs have their own memory. If program A could overwrite stuff
    from program B, even by accident you would have an unholy mess. You
    could never trust anything.




    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne
  • From Robert Nichols@110:300/1.1 to All on Thu Jan 12 17:35:01 2012
    On 01/11/2012 03:51 PM, bmearns wrote:
    On Jan 9, 10:47 pm, William Colls<william.co...@rogers.com> wrote:
    I'm no expert in this, but it would seem to me, that once the program is
    suspended, and the key removed, the program would also de-allocate any
    memory it is holding, and on any kind of reasonably busy machine, that
    memory is going to be fairly quickly re-allocted to something else and
    over written. But I'm really just guessing.

    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices. If I just use malloc to keep grabbing
    memory until the call fails, that should work, right? It will page
    anything it needs to keep, but those deallocated blocks of decrypted
    data should be fair game.

    You would also have to perform some write operation in each page. Newly malloc()-ed memory starts out as a copy-on-write mmap() of /dev/zero.

    --
    Bob Nichols AT comcast.net I am "RNichols42"

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: Exiguous (110:300/1.1@linuxnet)
  • From bmearns@110:300/1.1 to All on Fri Jan 13 19:21:18 2012
    On Jan 11, 8:54=A0pm, unruh <un...@invalid.ca> wrote:
    On 2012-01-11, bmearns <mearn...@gmail.com> wrote:

    On Jan 9, 10:47?pm, William Colls <william.co...@rogers.com> wrote:
    On 01/09/2012 10:04 PM, bmearns wrote:
    [snip]
    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by
    swapping.

    No It has no idea that the data it has in memory is the same as the data
    on disk. After all programs often change data in the course of their exectution. In fact that is usually the whole purpose of programs.
    Once a program reads data from disk into memory, that data is different
    from the data on the disk, and it had better get chached AND swapped.

    One of us is a little confused, and it may very well be me, but let me
    try to explain. When a program reads from file, the kernel caches the
    data from the file in page-sized blocks in memory. This is the page
    cache. It knows that these cached pages came from file, that's the
    whole point of caching them, so future accesses to the same area of
    the same file don't need to go back to disk. Whether or not the kernel
    is actually smart enough not to copy these to swap space or not I'm
    not sure, but it does know that they already exist on disk, and
    logically, I don't see any reason it couldn't decide that there's no
    need to copy them to swap. It's a little different if the cache has
    been written to and is dirty, but even then, the kernel could
    conceivably decide to just write that page back to the disk it came
    from, instead of to swap space. Again, whether or not it actually does
    that I don't know, (actually, that's the information that I'm looking
    for).

    I wonder if you're talking not about cached data, but about user data,
    which I hadn't thought of before, and is a legitimate concern. For
    instance, if a program reads from file, yes, there are 4KB of that
    file's data cached in RAM that the kernel knows all about, but there's
    all X bytes in the program's virtual memory, which the kernel is not
    keeping track of. If I recall correctly, even after that program
    exists, it's data persists in RAM until that physical RAM is allocated
    to another program.



    So now I just have to worry about anything cached in RAM, which is a
    bummer, because the whole point of this is to purge all the data
    without having to power cycle.

    -Brian

    I'm no expert in this, but it would seem to me, that once the program =
    is
    suspended, and the key removed, the program would also de-allocate any
    memory it is holding, and on any kind of reasonably busy machine, that
    memory is going to be fairly quickly re-allocted to something else and
    over written. But I'm really just guessing.

    Why would it deallocate its memory if it is just suspended? You could
    restart it. DO you mean if the program is stopped?
    Then yes, the memory will get dumped back to theheap, or the stack.
    But it is not erased.

    The suspension I was referring to was when the dm_crypt volume is
    suspended, not a program. According to the dm_crypt man page,
    suspending a volume removes the key from kernel memory; though I'm
    wondering now that I see all the other RAM security wholes if it even
    bothers to actually erase the key, or just frees the block where it's
    stored.



    True, but I would think "fairly quickly" could still be a matter of
    hours left to it's own devices. If I just use malloc to keep grabbing memory until the call fails, that should work, right? It will page
    anything it needs to keep, but those deallocated blocks of decrypted
    data should be fair game.

    No. programs have their own memory. If program A could overwrite stuff
    from program B, even by accident you would have an unholy mess. You
    could never trust anything.

    I'm not talking about overwriting data still in use, I'm talking about overwriting data that's been left behind by closed programs. As you
    mentioned, when a program exits, it's memory just goes back to the
    pool, it's not erased. So if another program asks for all available
    memory, it should get all those unused pages so it can erase them.


    -Brian



    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: http://groups.google.com (110:300/1.1@linuxnet)
  • From Alexander Schreiber@110:300/1.1 to All on Sun Jan 15 23:20:49 2012
    Richard Kettlewell <rjk@greenend.org.uk> wrote:

    I think you're OK on this one; AFAIK the buffer cache is not swapped.
    (It's hard to see what the point of doing so would be.)

    You may want to ask the dude at Microsoft who implemented that "feature"
    for Windows NT way back then. After the discovery of this .. suboptimal behaviour[0], it was IIRC fixed in later versions of Windows. ;-)

    Kind regards,
    Alex.
    [0] Although I suspect that someone simply forgot to mark the buffer cache
    as exempt from swapping[1].
    [1] Yes, NT _does_ swap kernel memory.
    --
    "Opportunity is missed by most people because it is dressed in overalls and
    looks like work." -- Thomas A. Edison

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: Not much. (110:300/1.1@linuxnet)
  • From Aragorn@110:300/1.1 to All on Mon Jan 16 00:16:02 2012
    On Sunday 15 January 2012 23:20, Alexander Schreiber conveyed the
    following to comp.os.linux.security...

    Richard Kettlewell <rjk@greenend.org.uk> wrote:

    I think you're OK on this one; AFAIK the buffer cache is not swapped.
    (It's hard to see what the point of doing so would be.)

    You may want to ask the dude at Microsoft who implemented that
    "feature" for Windows NT way back then. After the discovery of this .. suboptimal behaviour[0], it was IIRC fixed in later versions of
    Windows. ;-)

    Kind regards,
    Alex.
    [0] Although I suspect that someone simply forgot to mark the buffer
    [cache
    as exempt from swapping[1].
    [1] Yes, NT _does_ swap kernel memory.

    And although I don't know how things are in the current versions of
    Windows, but in the past Windows would also cache the swapfile... ;-)

    --
    = Aragorn =
    (registered GNU/Linux user #223157)

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (110:300/1.1@linuxnet)
  • From Jim Beard@1:0/0 to All on Thu Jun 14 14:51:56 2012
    On 01/13/2012 01:21 PM, bmearns wrote:
    On Jan 11, 8:54 pm, unruh <un...@invalid.ca> wrote:
    On 2012-01-11, bmearns <mearn...@gmail.com> wrote:

    On Jan 9, 10:47?pm, William Colls <william.co...@rogers.com> wrote:
    On 01/09/2012 10:04 PM, bmearns wrote:
    [snip]
    Thanks, Richard. I guess it makes sense that the data would not be
    swapped: as far as the kernel knows, any file data it's cached is
    already on disk, it would be pointless to put it on another disk by
    swapping.

    Not so. Reading and writing swap is much faster than reading and
    writing a normal file system, and is used for that reason even
    when data in memory and in a regular file system are identical.

    Cheers!

    jim b.

    --
    UNIX is not user unfriendly; it merely
    expects users to be computer-friendly.



    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne