Re: [Help] How to Replace File Operations in File System?
Hi Rishi, With pleasure! You can check it on https://github.com/freemandealer/droidcry on your convenience. 2014-02-19 23:17, Rishi Agrawal :
Good that you solved it your self, still if you can send me the idea on which you are working - I may also learn something.
On Tue, Feb 18, 2014 at 10:04 AM, freeman <freeman.zhang1992@gmail.com <mailto:freeman.zhang1992@gmail.com>> wrote:
> Hi > > The operations will not change back until your object gets destroyed, > whatever be the type of the object. > > Caching will not cause any issue here. > > Maybe if you can send the code we can have a look at it. > > > -- > Regards, > Rishi Agrawal Hi Rishi,
It's very nice of you willing to help check my code! I'm now very excited － problem solved!
I spent half a day beautifying my code yesterday (so that it won't annoy you that much), and find there is a problem:
Every time there is a read/write system call, I saved the lower file ops and address space ops. In their replacement(upper operations), I invoked lower ones. There's a possibility that it might saved the upper operations as lower ones if I open them twice in a short time. At this point, upper operation invoke itself! So I check the operations before truly save and replace them and, it works!
Thanks to you and all the amazing people in this amazing list that helped me, now I get both wrapfs and my own non-filesystem module functional for my future work on transparent encryption, and most importantly, I've learned and enjoyed a lot!
Regards Freeman Zhang
-- Regards, Rishi Agrawal Regards Freeman Zhang
Hi, I went through your readme. Some questions. On Thu, Feb 20, 2014 at 7:02 AM, freeman <freeman.zhang1992@gmail.com>wrote:
Hi Rishi,
With pleasure! You can check it on https://github.com/freemandealer/droidcry on your convenience.
2014-02-19 23:17, Rishi Agrawal :
Good that you solved it your self, still if you can send me the idea on which you are working - I may also learn something.
On Tue, Feb 18, 2014 at 10:04 AM, freeman <freeman.zhang1992@gmail.com>wrote:
Hi
The operations will not change back until your object gets destroyed, whatever be the type of the object.
Caching will not cause any issue here.
Maybe if you can send the code we can have a look at it.
-- Regards, Rishi Agrawal Hi Rishi,
It's very nice of you willing to help check my code! I'm now very excited － problem solved!
I spent half a day beautifying my code yesterday (so that it won't annoy you that much), and find there is a problem:
Every time there is a read/write system call, I saved the lower file ops and address space ops. In their replacement(upper operations), I invoked lower ones. There's a possibility that it might saved the upper operations as lower ones if I open them twice in a short time. At this point, upper operation invoke itself! So I check the operations before truly save and replace them and, it works!
Thanks to you and all the amazing people in this amazing list that helped me, now I get both wrapfs and my own non-filesystem module functional for my future work on transparent encryption, and most importantly, I've learned and enjoyed a lot!
Regards Freeman Zhang
-- Regards, Rishi Agrawal
Regards Freeman Zhang
1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module. 2. How can the user selectively encrypt the files in the system. -- Regards, Rishi Agrawal
2014-02-20 15:31, Rishi Agrawal :
Hi,
I went through your readme. Some questions.
1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.
2. How can the user selectively encrypt the files in the system.
-- Regards, Rishi Agrawal Hi Rishi,
Sorry about the fuzziness. #1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system. #2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present. Regards Freeman
On Thu, Feb 20, 2014 at 2:27 PM, freeman <freeman.zhang1992@gmail.com>wrote:
2014-02-20 15:31, Rishi Agrawal :
Hi,
I went through your readme. Some questions.
1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.
2. How can the user selectively encrypt the files in the system.
-- Regards, Rishi Agrawal
Hi Rishi,
Sorry about the fuzziness.
#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.
#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.
Why does it even matter - inode vs directory? Is it because you store the encryption metadata in the dirent and not the inode?
Regards Freeman
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Sandeep. "To learn is to change. Education is a process that changes the learner."
2014-02-2017:10, SandeepKsinha :
On Thu, Feb 20, 2014 at 2:27 PM, freeman <freeman.zhang1992@gmail.com <mailto:freeman.zhang1992@gmail.com>> wrote:
2014-02-20 15:31, Rishi Agrawal :
Hi,
I went through your readme. Some questions.
1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.
2. How can the user selectively encrypt the files in the system.
-- Regards, Rishi Agrawal
Hi Rishi,
Sorry about the fuzziness.
#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.
#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.
Why does it even matter - inode vs directory? Is it because you store the encryption metadata in the dirent and not the inode?
Regards Freeman
-- Regards, Sandeep.
"To learn is to change. Education is a process that changes the learner."
Hi Sandeep, Actually I haven't got that far... However as I planed it, I don't want involve the user too much- just to keep simple. I plan to build a safe box, and people throw personal things into it. That's all. I want to use it with Android devices. Will complex implementation build barrier for ebedded system? Any suggestions? Regards Freeman Zhang
On Thu, Feb 20, 2014 at 3:18 PM, freeman <freeman.zhang1992@gmail.com>wrote:
2014-02-2017:10, SandeepKsinha :
On Thu, Feb 20, 2014 at 2:27 PM, freeman <freeman.zhang1992@gmail.com>wrote:
2014-02-20 15:31, Rishi Agrawal :
Hi,
I went through your readme. Some questions.
1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.
2. How can the user selectively encrypt the files in the system.
-- Regards, Rishi Agrawal
Hi Rishi,
Sorry about the fuzziness.
#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.
#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.
Why does it even matter - inode vs directory? Is it because you store the encryption metadata in the dirent and not the inode?
Regards Freeman
-- Regards, Sandeep.
“To learn is to change. Education is a process that changes the learner.”
Hi Sandeep,
Actually I haven't got that far... However as I planed it, I don't want involve the user too much－ just to keep simple. I plan to build a safe box, and people throw personal things into it. That's all. I want to use it with Android devices. Will complex implementation build barrier for ebedded system? Any suggestions?
Not really. Just try to keep the implementation close enough to the use-cases you want to target. Make is user-centric rather than developer. All the best!
Regards Freeman Zhang
-- Regards, Sandeep. “To learn is to change. Education is a process that changes the learner.”
On Thu, 20 Feb 2014 17:48:07 +0800, freeman said:
However as I planed it, I don't want involve the user too much- just to keep simple. I plan to build a safe box, and people throw personal things into it. That's all.
The first question is - what are you trying to protect against? The answer to that will influence your design. As Bruce Schneier said in the intro to Applied Cryptography: There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files. This book is about the latter. It's one thing to write a silly kernel module that will rot13 your files. It's totally another to design a complete system that works. Do you need to worry about a directory being open for access to encrypted files, and another rogue process on the system simply going and reading the files and the crypto doesn't matter? (This is an issue for cryptLUKS, for instance - it defends against somebody stealing a powered-off laptop, but not against processes that get access to a running system. You may wish to think for a bit about what security is provided by a system that is suspended, rather than powered off - particularly in the case of cold-boot attacks....) Do you need to worry about somebody replacing the binary that prompts the user for the passphrase before loading it into the kernel, with a version that saves the passphrase for later, after the device has been "recovered" via theft or similar? (And yes, this *has* been used before, see 'FBI v Scarfo', where they installed a keylogger to snag a PGP passphrase: https://epic.org/crypto/scarfo.html Do you need to worry about other more generic keystroke loggers? Do you need to worry about the fact that most user passphrases won't have enough entropy to be used directly as crypto keys? If you merely use the passphrase for salting a randomized key (such as the way gpg, ssh, and cryptLUKS use your passphrase), how do you address the problem of insufficient random entropy at key generation time? That's just the obvious stuff you will need to worry about. :)
Hi, Sorry about the delayed response. To be frank, I haven't think over these stuff seriously. I didn't expect too much about the module at first. Now I know I was wrong. I shouldn't get through it rashly-people are watching on me! And I believe I can make it with the help and advice I got from all of you. Thank you!
The first question is - what are you trying to protect against? The answer to that will influence your design.
As Bruce Schneier said in the intro to Applied Cryptography:
There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files. This book is about the latter.
It's one thing to write a silly kernel module that will rot13 your files. It's totally another to design a complete system that works.
Do you need to worry about a directory being open for access to encrypted files, and another rogue process on the system simply going and reading the files and the crypto doesn't matter? (This is an issue for cryptLUKS, for instance - it defends against somebody stealing a powered-off laptop, but not against processes that get access to a running system. You may wish to think for a bit about what security is provided by a system that is suspended, rather than powered off - particularly in the case of cold-boot attacks....)
Do you need to worry about somebody replacing the binary that prompts the user for the passphrase before loading it into the kernel, with a version that saves the passphrase for later, after the device has been "recovered" via theft or similar? (And yes, this *has* been used before, see 'FBI v Scarfo', where they installed a keylogger to snag a PGP passphrase:
https://epic.org/crypto/scarfo.html
Do you need to worry about other more generic keystroke loggers?
Do you need to worry about the fact that most user passphrases won't have enough entropy to be used directly as crypto keys? If you merely use the passphrase for salting a randomized key (such as the way gpg, ssh, and cryptLUKS use your passphrase), how do you address the problem of insufficient random entropy at key generation time?
That's just the obvious stuff you will need to worry about. :)
Regards Freeman Zhang
participants (5)
-
freeman -
Freeman Zhang
-
Rishi Agrawal -
SandeepKsinha -
Valdis.Kletnieks＠vt.edu