On Thu October 1 2009, Michael S. Zick wrote: > On Thu October 1 2009, Michael D. Adams wrote: > > On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt <g...@hobbelt.com> wrote: > > > A note about your mention of 'security leak': when you are worried > > > about adversaries who can run 'ps -l' on your machine, then you're > > > essentially worried about adversaries with plenty of access to your > > > machine, so they'll quite probably be able to 'cat' that keyfile > > > > Any normal user on a Linux machine would be able to see 'ps -f'. But > > to 'cat' the keyfile or coredump the app, they would need to either > > (1) have root access, or (2) have cracked the machine. In my mind > > there is a large leap between 'normal users could get this secret > > info' and 'user's with root access could get this secret info'. > >
I'll stick by this part of my post: > > Misplaced security barrier - > - - - - > > Other than those operational procedures, you should at least write > your own application that does not disclose what you want hidden. > Which might be anything from a small script to tons of compiled code. The actual solution depends on your situation, the principle remains. The question remains, what do I mean by "Misplaced Security Barrier"? (And I will avoid the artifact of second hand smoke this time.) If it is only the file data that needs protecting; then an example might be similar to the GIT utility with a Truecrypt volume for the data store. That puts the security barrier at the Truecrypt boundary. From the content of the other posts, that will not give you the solution you are seeking. Considering a generalized "Content Identification Filesystem" - where the content ID is a replacement or substitute for the pathname/filename - A "flat" file system where only a secure hash of the content is the access token, rather than its storage location expressed as a pathname/filename. Just to give the above puff of smoke a bit body, consider - In a medical records system the information access token might be the patents name and social security number - something you don't want 'published'. So you have substituted a secure hash of that information for the access token. But from the original post, I read that you don't want that secure hash 'published'. You want the 'security barrier' between the keyboard clerk and the access token. Just like you don't want the keyboard clerk to type the name & number (I.E: 'non-published'); you don't want the keyboard clerk to type the secure hash (which would, in this example, also 'publish' it). Here, you want your security barrier between the 'published' and 'non-published' at the clerk's input part of the system. (to protect any traces of what the clerk types from others - by any means, system or physical snooping.) Which gets you to the second part of my post - you'll have to write something. I.E: hide the transition from 'published' to 'non-published' inside of code and then protect that code and its execution. Mike > Mike > > > Michael D. Adams > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager majord...@openssl.org > > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
