| Author |
preventing program from being swapped out
|
|
| Matthias Czapla 2004-03-28, 2:34 pm |
| Hi!
How can I prevent a program from being swapped out to disk. The program
reads encrypted data from disk, works on it and writes it encrypted to
disk again. The memory containing the sensitive data is overwritten
with zero bytes on exit. Now when it gets swapped out with the
cleartext data in memory, the sensitive data is also on the disk which
I want to avoid.
Regards
Matthias
| |
| Måns Rullgård 2004-03-28, 2:34 pm |
| Matthias Czapla <derlalert@netscape.net> writes:
> Hi!
>
> How can I prevent a program from being swapped out to disk. The program
> reads encrypted data from disk, works on it and writes it encrypted to
> disk again. The memory containing the sensitive data is overwritten
> with zero bytes on exit. Now when it gets swapped out with the
> cleartext data in memory, the sensitive data is also on the disk which
> I want to avoid.
Use mlock() or mlockall(). However, it is still trivial to access the
memory of the process, think debugger.
--
Måns Rullgård
mru@kth.se
| |
| Rich Teer 2004-03-28, 2:34 pm |
| On Sun, 28 Mar 2004, Matthias Czapla wrote:
> How can I prevent a program from being swapped out to disk. The program
Lock all the pages in RAM.
> reads encrypted data from disk, works on it and writes it encrypted to
> disk again. The memory containing the sensitive data is overwritten
> with zero bytes on exit. Now when it gets swapped out with the
Why wait that long? Why not overwrite it with zeros once you've
encrypted it?
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Matthias Czapla 2004-03-28, 3:34 pm |
| Måns Rullgård wrote:
> Matthias Czapla <derlalert@netscape.net> writes:
>
> Use mlock() or mlockall().
Ok, thanks.
> However, it is still trivial to access the
> memory of the process, think debugger.
I dont want to prevent the owner of the data from accessing it, only others
Regards
Matthias
| |
| Matthias Czapla 2004-03-28, 3:34 pm |
| Rich Teer wrote:
> On Sun, 28 Mar 2004, Matthias Czapla wrote:
>
> Lock all the pages in RAM.
>
>
> Why wait that long? Why not overwrite it with zeros once you've
> encrypted it?
Thats what Im doing. The encryption takes place on exit if the data has been
modified (in contrast to only examining it).
Regards
Matthias
| |
| Jem Berkes 2004-03-28, 3:34 pm |
| > I dont want to prevent the owner of the data from accessing it, only
> others
>
I understand what you're doing and it sounds like a nice step for increased
security. However, if the OS is incapable of providing privilege isolation
and protection then you have some big problems that will probably
overshadow your efforts to protect your data with system calls.
--
Jem Berkes
http://www.sysdesign.ca/
| |
| Måns Rullgård 2004-03-28, 3:34 pm |
| Matthias Czapla <derlalert@netscape.net> writes:
> Måns Rullgård wrote:
>
> Ok, thanks.
>
>
> I dont want to prevent the owner of the data from accessing it, only others
No normal user should have access to the swap space either. However,
you might of course fear that someone puts the disk in another machine
and reads it there.
--
Måns Rullgård
mru@kth.se
| |
| Jens.Toerring@physik.fu-berlin.de 2004-03-28, 4:34 pm |
| Måns Rullgård <mru@kth.se> wrote:
> Matthias Czapla <derlalert@netscape.net> writes:
[color=darkred]
> Use mlock() or mlockall(). However, it is still trivial to access the
> memory of the process, think debugger.
But at least under Linux that requires root privileges, doesn't it?
And I would guess that also other Unices would require something
similar (otherwise a malicious or bady written program could use
up all or at least a lot of the physical memory). Fortunately, at
least under Linux, you can't attach to a processes running with
root privileges, so a debugger isn't that much of a problem (but
everyone with root privileges can of course take a peak at the
memory directly).
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
| |
| Dmitry Karasik 2004-03-28, 4:34 pm |
|
Måns> No normal user should have access to the swap space either.
Måns> However, you might of course fear that someone puts the disk in
Måns> another machine and reads it there.
Unless the program runs on OpenBSD with its encrypted swap files.
--
Sincerely,
Dmitry
--- www.karasik.eu.org ---
The woods are full of people who want this job -- Dilbert
| |
| Matthias Czapla 2004-03-28, 5:35 pm |
| Måns Rullgård wrote:
> Matthias Czapla <derlalert@netscape.net> writes:
>
> Use mlock() or mlockall(). However, it is still trivial to access the
> memory of the process, think debugger.
As someone pointed out in another post, mlock requires root privileges.
My program is intended to be run by ordinary users.
Regards
Matthias
| |
| Matthias Czapla 2004-03-28, 11:38 pm |
| Jem Berkes wrote:
>
> I understand what you're doing and it sounds like a nice step for increased
> security. However, if the OS is incapable of providing privilege isolation
> and protection then you have some big problems that will probably
> overshadow your efforts to protect your data with system calls.
I guess since its not possible to keep the root user away from the memory
of the user process anyway its probably not worth the trouble. Allthough
I really dont like the idea of sensitive information laying around on disk
for an indeterminable amount of time...
Regards
Matthias
| |
| Francis 2004-03-29, 4:41 am |
| Le 29-03-2004, Matthias Czapla <derlalert@netscape.net> a écrit_:
>
> I guess since its not possible to keep the root user away from the memory
> of the user process anyway its probably not worth the trouble. Allthough
> I really dont like the idea of sensitive information laying around on disk
> for an indeterminable amount of time...
I think some unices provide the admin with encrypted swap-space. You
could try it.
Francis.
| |
| Jem Berkes 2004-03-29, 9:49 am |
| >> I understand what you're doing and it sounds like a nice step for
>
> I guess since its not possible to keep the root user away from the
> memory of the user process anyway its probably not worth the trouble.
> Allthough I really dont like the idea of sensitive information laying
> around on disk for an indeterminable amount of time...
Those functions for kernel page locking are root-only I believe (as I think
you discovered). For instance, gpg requires that the binary is suid root in
order to lock its pages.
Your app, like gpg, has to balance the security risk of running suid root
against the security risk of allowing its pages to be swapped or otherwise
relocated. I personally believe the risk of running suid root is a greater
problem.
--
Jem Berkes
http://www.sysdesign.ca/
| |
| Måns Rullgård 2004-03-29, 9:49 am |
| Jem Berkes <jb@users.pc9.org> writes:
>
> Those functions for kernel page locking are root-only I believe (as I think
> you discovered). For instance, gpg requires that the binary is suid root in
> order to lock its pages.
>
> Your app, like gpg, has to balance the security risk of running suid root
> against the security risk of allowing its pages to be swapped or otherwise
> relocated. I personally believe the risk of running suid root is a greater
> problem.
If you lock down the pages you need before doing anything else, and
the drop the privileges the security problem becomes minimal.
--
Måns Rullgård
mru@kth.se
| |
| Matthias Czapla 2004-03-29, 12:38 pm |
| Jem Berkes wrote:
> Your app, like gpg, has to balance the security risk of running suid root
> against the security risk of allowing its pages to be swapped or otherwise
> relocated. I personally believe the risk of running suid root is a greater
> problem.
I agree, especially because my program exec's arbitrary user provided
shell commands.
Regards
Matthias
|
|
|
|