Re: Design Issue - Transparent interface to some encrypted files

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

 




Thanks Brian and Vecna,


That was helpful.. I have to take a look at umpf and kumpf. I believe one of them would be sufficient for me. I could always go with an encrypted filesystem partition and have links to my files as Vecna suggested but there is not much fun in it :) I think for my project I will be forced to go with that option though. I will consider the options (including the LKM) I have and let you guys know.

Srinivas

From: Brian Rossa <brossa@cns.bu.edu>
To: Srinivas Vedula <vedula7@hotmail.com>, kernelnewbies <kernelnewbies@nl.linux.org>
Subject: Re: Design Issue - Transparent interface to some encrypted files
Date: Sun, 14 Dec 2003 16:28:46 -0500
MIME-Version: 1.0
Received: from fenway.bu.edu ([128.197.61.100]) by mc3-f22.hotmail.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 14 Dec 2003 13:28:47 -0800
Received: from cns.bu.edu (cns-pc55.bu.edu [128.197.61.202])by fenway.bu.edu (8.12.8/8.12.8) with ESMTP id hBELSkIm029902;Sun, 14 Dec 2003 16:28:46 -0500
X-Message-Info: JGTYoYF78jG8lUSKWAVLG3b1JOc8+Col
Message-ID: <3FDCD60E.7010104@cns.bu.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
References: <BAY9-F3299d2K5a7g1t000557a3@hotmail.com>
In-Reply-To: <BAY9-F3299d2K5a7g1t000557a3@hotmail.com>
Return-Path: brossa@cns.bu.edu
X-OriginalArrivalTime: 14 Dec 2003 21:28:47.0478 (UTC) FILETIME=[42474160:01C3C289]


Hey,

I was working with a similar issue a couple of weeks ago. Check the archives for some of the advice I was given.

Just to recap: I wanted to catch all the open, read, and write system calls and perform some operations before the file actually got handed back from the kernel. In the past, it has been very easy to overload system calls in a loadable kernel module by just getting a pointer to, say, the read() system call and replacing it with a pointer to my_read(). Pointers to various system calls could be obtained by simply calling export sys_call_table() in your module. Redhat (in v2.4 kernels) and Linus (in v2.6 kernels) have decided that this is too much of a security hole. It allows script kiddies to sit on your box undetected by running their evil behind the authority of the kernel. You can no longer export the system call table.

The moral of the story is that I have been struggling with this problem for a while, and as of yet there is not a good solution. File locks do not send signals to the locking process. The new LSM is ugly, and it totally unclear as to how to get this sort of thing done under the LSM framework. As far as I can tell, you simply cant interpose code between the user and the kernel any more. Is this good? In our new securitarian society the consensus seems to be yes.

Good luck,

Brian Rossa
Dept. of Cognitive
& Neural Systems
Boston University



Srinivas Vedula wrote:


Hello,


I am trying to write a transparent interface to some encrypted files so that the user does not notice that the files are stored encrypted. All the files are encrypted using the same key and algorithm.

As a quick hack I thought of catching the necessary system calls ( like open, read, write) do the necessary encryption, decryption and return the data to the user. This will work with write as the processing is done before calling the system call. But with read the processing has to be done after the system call completes. This can be may be done by changing the way system calls are returned in entry.S. But I am not sure how to do this.

Could some one suggest if this is a good way to proceed or if there is a better solution to this. I do not want to use an encrypted filesystem because the files are very few and part of different directories.

Thanks,
Srinivas

_________________________________________________________________
Shop online for kids? toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/



_________________________________________________________________
Tired of slow downloads and busy signals? Get a high-speed Internet connection! Comparison-shop your local high-speed providers here. https://broadband.msn.com


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux