From: apawar.linux@gmail.com (Abhijit Pawar)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Filtering USB storage data in kernel module
Date: Fri, 18 Nov 2011 21:05:48 +0530 [thread overview]
Message-ID: <4EC67B54.1010102@gmail.com> (raw)
In-Reply-To: <20111118144614.GA1443@kroah.com>
On 11/18/2011 08:16 PM, Greg KH wrote:
> On Fri, Nov 18, 2011 at 06:36:18PM +0530, Abhijit Pawar wrote:
>> On 11/17/2011 08:19 PM, Greg KH wrote:
>>> On Thu, Nov 17, 2011 at 02:15:35PM +0530, Abhijit Pawar wrote:
>>>> Hi All,
>>>> I need to filter the data written/read to and from the USB storage
>>>> disk.
>>> Why?
>> I want to build a secure machine with data protection. I want to
>> have a security around the machine where anyone can attach a usb
>> disk and copy the data. but i want to make the copied data useless
>> unless it has the trust relation with the host to which its
>> connected.
>> So if one has copied data from one secured machine and get that usb
>> disk to other machine, he should see the encrypted garbage data.
> Interesting idea.
>
>>> What are you wanting to do at "filter" time?
>> I want to encrypt the write data packets and decrypt the read data packets.
>>> Why just USB disks? What makes them special?
>> They are the one which can be attached to the system easily.
>>> How are you going to determine if a disk is a USB device or not?
> You forgot to answer this question :)
Yeah, I forgot that one. I am not very sure but if I can patch the USB
core before it attaches the speficied class driver to the USB device.
May be I can try and send some control request and get the class of the
device. I think its not required as USB core itself will understand the
class of the device and try to attach the proper driver. At this point
of time, I will have some patch which will pass on the information to my
module.
I am not sure if there are any intercepting points or any functions /
structures exported in the USB core stack.
>
>>>> Now the way USB is made known to OS is through SCSI and then
>>>> respective filesystem ( mostly usbfs).
>>> Not really, usbfs is only one way, and it has nothing to do with usb
>>> disks.
>>>
>>>> So is there any way I can intercept this stack and have my kernel module
>>>> invoked so that I will get the data.
>>> Not easily.
>> Even if its hard, can you please give details of how do I achieve this?
>>>> I have been thinking on two approaches:
>>>>
>>>> 1. Use VFS and write a proxy filesystem for USB device which will filter
>>>> the data.
>>>> 2. checking SCSI and any intercepting point.
>>> Again, what are you trying to "filter"? That will determine where you
>>> make changes.
>> thanks, greg k-h
>> So what choice do I have now for this?
> Lots of work, best of luck with this task, it will not be simple or
> easy.
>
> greg k-h
Thanks. Its not that simple. I need to check the sCSI family code as
well as USB core. Also VFS may be involved. :( :)
Regards,
Abhijit Pawar
next prev parent reply other threads:[~2011-11-18 15:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 8:45 Filtering USB storage data in kernel module Abhijit Pawar
2011-11-17 14:49 ` Greg KH
2011-11-18 13:06 ` Abhijit Pawar
2011-11-18 14:46 ` Greg KH
2011-11-18 15:35 ` Abhijit Pawar [this message]
2011-11-21 13:55 ` Abhijit Pawar
2012-01-12 7:03 ` Abhijit Pawar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC67B54.1010102@gmail.com \
--to=apawar.linux@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.