On Wed, Apr 22, 2015 at 9:23 AM, John McKown <john.archie.mckown at gmail.com>
wrote:
> On Wed, Apr 22, 2015 at 8:14 AM, Simon Slavin <slavins at bigfraud.org>
> wrote:
>
>>
>> On 22 Apr 2015, at 2:07pm, Paul Sanderson <sandersonforensics at gmail.com>
>> wrote:
>>
>> > You haven't said what operating system you are using
>>
>> Sorry, but I can't. However, the OS is strongly oriented towards
>> security paranoia. As long as the proper OS calls are used to delete files
>> and release memory, you can assume that they are unrecoverable, with all
>> the stuff a forensic expert would hate. The same is true of any caching
>> done at OS level or below (e.g. device drivers, storage which automatically
>> manages sector usage, etc.).
>>
>> > This might be a level of access you are not concerned with - I guess
>> > that all depends on how sensitive sensitive is :)
>>
>> You got it. But the platform (OS and hardware) is specially designed for
>> this. As you suspected I'm concerned only at the level of filespace which
>> is still in use.
>>
>> Simon.
>>
>
> ?Well, it is difficult, if not completely impossible to say without
> knowing the OS involved. But since you indicated "strongly oriented towards
> security paranoia", I am certain that it cannot be from Microsoft. If it is
> a POSIX compliant, perhaps what you could do is create a "temporary"
> (mktemp) file of "appropriate" size. Now create an encrypted filesystem
> into that file. Mount this filesystem "somewhere". Make it the current
> directory. Create all your databases
>
?inside it.?
?OOPS my example is not encrypted. But there are things such as LUKS to do
that as well, if necessary. After re-reading your post, I don't think
encryption is needed on your OS.
>
> # Example in Linux
> cd /somewhere
> tfile=$(mktemp -p .) #create temporary file
> dd if=/dev/zero of=${tfile} bs=1024 count=1048576 # 1 gig
> mkdir tempfs
> sudo mount ${tfile} tempfs #mount the temporary file system
> rm ${tfile} #remove temp file while leaving it mounted
> cd tempfs #make tempfs the working directory
> ... do sqlite3 program(s) here
> cd ..
> sudo umount tempfs #unmount, which will remove inode as well
>
>
> ?Of course, I don't know if your OS can do the above because you can't say
> anything about it. Also, I showed this as a shell script, but you could do
> the equivalent in your application program before initializing the SQLite
> environment. If you want/need to, you could do the unlink() (rm command)
> _after_ terminating the the SQLite environment, unmounting the filesystem,
> and overwrite the file contents before doing the unlink() to delete it.?
>
> ?In any case, even if you can't do exactly the above, perhaps it will
> spark some other idea for you.
>
> --
> If you sent twitter messages while exploring, are you on a textpedition?
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>
--
If you sent twitter messages while exploring, are you on a textpedition?
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
