Virtual Encrypted File System (VEFS)

[Rick Langschultz]

Through an intriguing article on Slashdot I have read that ipods are  
now being used for things other than audio. They are being used to  
obtain data from a computer, and computer network obtaining business  
documents and such in seconds.

One way to make ReactOS a safer operating environment is to use a  
virtual encrypted file system that would restrict the copying of  
files to any usb, or network device via an encryption algorithm. So I  
propose a VEFS that would restrict this. The VEFS would disallow the  
passage of documents to any removable device unless the user has  
permission to archive them, which would be the "a" attribute. The  
VEFS would make use of two AES encryption algorithms which would  
encrypt the file's contents. One being a key another a lock, however  
the user must provide a password to unlock and decrypt the files.  
This would allow the user to unlock the files, only if they have the  
password. This would also allow users to secure their personal and  
corporate data.

Any ideas?

[D. Hazelton]

On Monday 20 February 2006 01:16, Rick Langschultz wrote:
> Through an intriguing article on Slashdot I have read that ipods are
> now being used for things other than audio. They are being used to
> obtain data from a computer, and computer network obtaining business
> documents and such in seconds.
>
> One way to make ReactOS a safer operating environment is to use a
> virtual encrypted file system that would restrict the copying of
> files to any usb, or network device via an encryption algorithm. So I
> propose a VEFS that would restrict this. The VEFS would disallow the
> passage of documents to any removable device unless the user has
> permission to archive them, which would be the "a" attribute. The
> VEFS would make use of two AES encryption algorithms which would
> encrypt the file's contents. One being a key another a lock, however
> the user must provide a password to unlock and decrypt the files.
> This would allow the user to unlock the files, only if they have the
> password. This would also allow users to secure their personal and
> corporate data.
>
> Any ideas?

At this point there could always be another filesystem flag. From recent 
traffic I think that ReactOS might wind up with something other than FAT or 
NTFS as a base filesystem. Whether it winds up with something like Ext3+Posix 
ACL's or a custom brewed filesystem is up to whoever is doing that work, but 
one could have an ACL on files for that permission or, in the case of the 
custom brewed filesystem, an actual permission in the filesystem.

Truly, though, I'd suggest ReactOS try to implement an NTFS driver, since NTFS 
already has the capability (as of the Win2000 version) to seemlessly compress 
or encrypt single files, directories or entire drives.

DRH

[M Bealby]

From: Rick Langschultz [e-mail]
Subject: [ros-dev] Virtual Encrypted File System (VEFS)
Date: Mon, 20 Feb 2006 00:16:35 -0600
> One way to make ReactOS a safer operating environment is to use a  
> virtual encrypted file system that would restrict the copying of  
> files to any usb, or network device via an encryption algorithm. So I  
> propose a VEFS that would restrict this. The VEFS would disallow the  
> passage of documents to any removable device unless the user has  
> permission to archive them, which would be the "a" attribute. The  
> VEFS would make use of two AES encryption algorithms which would  
> encrypt the file's contents. One being a key another a lock, however  
> the user must provide a password to unlock and decrypt the files.  
> This would allow the user to unlock the files, only if they have the  
> password. This would also allow users to secure their personal and  
> corporate data.

As pointed out by DRH, it's just another filesystem flag.  There isn't
actually any encryption process occuring in the method you described.
If the OS respects the flag then copying won't occur.  What you are
basically describing is a flag which disallows copying of a file.

If you do want to also encrypt the files, then it will not help in
this situation.  File system encryption only helps when the machine is
not running (technically, when the drive is not mounted).  When the
machine is running and the drive is visible then it provides no
advantages what-so-ever.

Personally, I don't think it's worth it.  If a user had read
permissions but not copy permissions it's would be very easy for them
to get around it.  They could copy and paste into another document,
perform a screen capture or even just print it.

While the idea behind the scheme is good, it's unworkable in reality.

Martin