I’m writing a utility that needs to use secure memory (that is, won’t
swap to disk). Is there a “best practices” way to do this with Ruby,
some common library that could be used for this purpose, et cetera?
Thanks in advance for any help.
On Fri, Feb 19, 2010 at 04:41:16PM +0900, Chad P. wrote:
I’m writing a utility that needs to use secure memory (that is, won’t
swap to disk). Is there a “best practices” way to do this with Ruby,
some common library that could be used for this purpose, et cetera?
What do you need to do exactly? Are you going to be allocating the
memory yourself? If so, you might want to look for wrappers around
mlock, and use the mmap gem.
If you’re talking about the entire ruby VM, I would suggest compiling
your own Ruby, but modifying the memory allocators to use something like
secmalloc:
On Fri, Feb 19, 2010 at 05:29:34PM +0900, Aaron P. wrote:
your own Ruby, but modifying the memory allocators to use something like
secmalloc:
I’m basically just looking to ensure that any data a small program
handles will not get written to disk. This is not intended to be
something only I (and specially prepared users) can employ, but rather a
program that can be used with a standard Ruby install without dumping
sensitive data to the swap partition if RAM usage gets too high, so
compiling my own Ruby interpreter/VM to behave the way I like isn’t
really an appropriate solution.
How exactly I’ll handle this in Ruby is dependent on the answer to my
question. If I have to allocate memory myself, so be it. If there’s
some Ruby library that can abstract away the heavy lifting, so much the
better (though I hadn’t found anything like that yet). At first glance,
it looks like Mmap might do it. I’ll look into that. Thank you for
mentioning it.
Do you happen to know off-hand if it leaks via the Ruby interpreter/VM
at
all?
On Feb 18, 2010, at 23:41 , Chad P. wrote:
I’m writing a utility that needs to use secure memory (that is, won’t
swap to disk). Is there a “best practices” way to do this with Ruby,
some common library that could be used for this purpose, et cetera?Thanks in advance for any help.
Don’t worry about it and employ the OS’s option for secured virtual
memory?
On Sat, Feb 20, 2010 at 08:39:21AM +0900, Ryan D. wrote:
On Feb 18, 2010, at 23:41 , Chad P. wrote:
I’m writing a utility that needs to use secure memory (that is, won’t
swap to disk). Is there a “best practices” way to do this with Ruby,
some common library that could be used for this purpose, et cetera?Thanks in advance for any help.
Don’t worry about it and employ the OS’s option for secured virtual memory?
Is there a means of doing so from within Ruby so that the OS-specific
details are abstracted away, thus allowing for a maintainable, portable
tool?
On Sat, Feb 20, 2010 at 09:45:47AM +0900, Ryan D. wrote:
AFAIK, secured virtual memory is a system-wide needs-a-reboot type of
thing. So other than good doco, I think the answer defaults to “no”. It
is the route I’d go. The software will be as clean as it can be,
easy(ier) to security audit, etc. All with the caveat, that you need to
run it in a secured environment. Given the original requirements, that
just seems common sense/expected to begin with.
I know that one does not need to reboot a computer to have a guarantee
that data in memory will not be swapped out. For an example, check the
way GnuPG works on BSD Unix and Linux systems if the SUID bit is set,
where it will start with administrative privileges to secure memory
against swapping to disk then drop administrative privileges to run as
the current user. That way, passwords, private keys, and cleartext data
that is being encrypted or decrypted will not be swapped to disk where
it
could be harvested later by a malicious security cracker more easily
than
it could from RAM.
Of course, GnuPG is not written in Ruby, which is why I’m not looking at
GnuPG source code for hints on how to do something similar in Ruby.
On Feb 19, 2010, at 15:51 , Chad P. wrote:
Don’t worry about it and employ the OS’s option for secured virtual memory?
Is there a means of doing so from within Ruby so that the OS-specific
details are abstracted away, thus allowing for a maintainable, portable
tool?
AFAIK, secured virtual memory is a system-wide needs-a-reboot type of
thing. So other than good doco, I think the answer defaults to “no”. It
is the route I’d go. The software will be as clean as it can be,
easy(ier) to security audit, etc. All with the caveat, that you need to
run it in a secured environment. Given the original requirements, that
just seems common sense/expected to begin with.