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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).