Re: making perl more forgetting

[ddzeko]

Except for the possibility of somebody breaking in and gaining root privileges I do not fear of (legitimate) root users stealing confidential data. I'm just concerned with the lack of possibility to overwrite string of characters to remove it's contents from memory and make my program more secure.

This program is running as daemon and since it's pretty stable (POE rocks) and does not leak memory it does not get restarted too often. It's the fact that it leaves the trail of it's confidential parameters in memory and that I cannot do anything about it that worries me.

Can I file it as a bug report? :)

Having wipe() in Perl would fix my problem and greatly improved Perl's useability in security related applications. Or having some keyword that would mark variable wipeable by the GC when the data is being released.

I'm looking forward to write userspace filesystem drivers in Linux using Perl, but I would not approach such thing without having means to destroy unwanted confidential data.

[flyingmoose]

Fair enough, but if you've been rooted, they can do whatever they want to your system, including installing keyloggers and shells around certain programs. It's especially dangerous when the hit is to take *future* data, so at that point, it's too late.

I'm looking forward to write userspace filesystem drivers in Linux using Perl

Very interesting in a sick-and-twisted sort of way... do you have any reference material on the subject? I wouldn't mind reading up on this. Naturally there is no way in heck I'd do this for anything than something that wanted to "act" like a virtual file system, wouldn't trust it to important data, etc, but it does sound cool.

[Anonymous Monk]

Installing keyloggers, wrappers and sniffers could not pass unnoticed by file integrity checker I plan to run. What bother me the most is that this grepping /dev/mem stuff works without having to install any additional program or modify an existing one. Possibility for other programs on that machine to malloc() their way to confidential data also gives me shivers. :)

Solution that I'm considering now (since I do not grok Perl guts so well to patch it to do wiping of some "hot variables") is to combine IPC::SharedCache and Tie::EncryptedHash. First one guarantees me that memory won't be freed by system to be used by some other module, and the other one makes it proof for simple grepattack. :) I'll be satisfied with such risk reduction measured by level of costs.

I could easily manage to make program also coredump-proof since memory accessed through IPC::SharedCache continues to live after program dies (or exec($0)'s itself). :) Not that it dumps cores, but sometimes when U're rapidly developing a live system you want to restart the damn thing without many users noticing that.

About the other thing -- userspace FS driver, that would be nice topic for some other thread, but just a few words, I'd like to create virtual filesystem which would be shared through Samba to workstations and would offer personalized view on some highly hierarchically organized application data: imagine: FS explorer as an aplication UI. :)