[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: crypto file system



Jan accidentally sent his last message to me instead to the list and asked me 
to forward it.

------

Greetings,
On Thu, Feb 24, 2005 at 09:46:50AM +0100, Jonathan Schmitt wrote:
> Hi back,...
> 
> > Stop. You are right. I misunderstood you.
> > I thought you want to exported the fs-image.
> > (But don't use journal-fs)
> > If you export the data only, there shouldn't be any problem.
> 
> So let's check whether or not I got You right. Say, I export the raw 
> loop-file, that contains the encrypted file system via NFS. If I mount this 
> file loop-back on several computers and concurrently write or read, the file 
> system cannot get screwed up (only because of the concurrent access)?

No, if you do it that way, the file is either read-only or screwed up.
(I thought you wanted mount the encrypted loop-back on your server and want
to share the no-longer-encrypted files).
 
> > Well every encrypted file is stored in cleartext while editing. Even if 
you 
> > use an encrypted partion. (In this case the key is stored in RAM and can 
be 
> > recovered locally)
> 
> That's right. However, I think it is a difference, whether the file is 
> unencrypted in the memory or unencrypted lying somewhere on the hard disk. 
If 
> it is unencrypted in the memory, it is much more difficult to obtain. I 
> think, we will agree on the fact, that 100% security is not possible, 
> however, it doesn't hurt to make it as hard as possible for the attacker.
> 
> > Not If you encrypt your working-directories randomly. Every time you boot,
> > you get a clean, new tmp and data recovery is impossible due to 
encryption.
> 
> Yes, would be a fine solution. However, You have to factor in the human 
factor 
> here. If You have one man in the chain, who decides that it is reasonable 
> enough to think no one hacks his machine and such precautions are a waste of 
> time and effort than the hole security concept falls apart. Therefore, I'm 
> looking for a solution that is transparent and as easy to use as possible 
(at 
> least, easier to use then to go around...).

Well, this can be done using fstab (for /tmp for instance)
 
> > Well, I haven't used it.
> > CFS is (imho) can be substituted with ssh and NFS-over-TCP.
> > Be aware, that CFS is quite obsolete.
> 
> Is the data encrypted on the server, when using ssh over NFS? That's one 
thing 
> that would really be nice...

No. You have to use loop-aes to do so. But if it's mounted to be shared, it
can be accees locallly.
If you don't wanna risk this, You can use samba with pre and post execution 
scripts to prevent this issue.
(but I it requires (perl-)coding)
(Anyway, samba allows very flexbile handling of shares be specifying
hack-scipts. If you know how to code, you may use samba as a backend, and do
the encryption you want in realtime. For instance you might use the users
password (non-encrypted on smb level (!)) as a passphrase for an asym.
encryption. By giving a key to each user you may handle it very flexible.
You will be also able to decrypt files in runtime by using gpgme (a libary
for gpg access without writing any data on HDs)

Keep smiling
yanosz



Reply to: