Mulyadi Santosa wrote:
Hi Avinash....
A small idea from non-fs expert...
I am trying to zero data blocks whenever an unlink is invoked as part
of a secure delete filesystem.
I checked your attached code and I tried to inspect how ext2-fs does
file write (it is just my assumption that you're using ext2). I hit on
generic_file_write(). From there, I hit __generic_file_write_nolock(),
followed by __generic_file_aio_write_nolock() (mm/filemap.c).
Interesting check happen here:
--------------------------------------------------------------------------
if (access_ok(VERIFY_READ, iv->iov_base, iv->iov_len))
continue;
--------------------------------------------------------------------------
From the access_ok() macro's comment:
"Note that, depending on architecture, this function probably just
checks that the pointer is in the user space range - after calling
this function, memory access functions may still return -EFAULT."
I see that you're using memory block allocated by kmalloc(GFP_KERNEL).
For a moment, I thought this won't be a problem since you already did :
set_fs(KERNEL_DS);
But.... in include/asm-i386/uaccess.h, looks like it is checking
directly to thread_info for thet segment limit, not in GDT or anything
else:
------------------------------------------------------------------------------
asm("addl %3,%1 ; sbbl %0,%0; cmpl %1,%4; sbbl $0,%0" \
:"=&r" (flag), "=r" (sum) \
:"1" (addr),"g" ((int)(size)),"rm"
(current_thread_info()->addr_limit.seg)); \
flag; })
------------------------------------------------------------------------------
Thus, it violates access_ok...and AFAIK, seems like write will return
with -EFAULT.
So, my suggestion is, either use kmalloc(GFP_USER) or simply use "shred"
to avoid this low level complexity.
How does it affect the access rights?
from gfp.h,
#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
and
#define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
Although I do not know what __GFP_HARDWALL means, (doc says enforce
hardwall cupset memory access), I recall in 2.4.x and early 2.6.X, both
GFP_KERNEL and GFP_USER were same.
And moreover, rather than doing gymnastics with GET_FS and SET_FS, OP
should try to access the blocks of data and clear or random fill them. I
am not a security expert, but there may be a lot better methods to
implement security at file level I think. (e.g,
http://wipe.sourceforge.net/,
http://www.usenix.org/events/sec01/full_papers/bauer/bauer_html/index.html
). As usual, google is your friend here.
Regads,
Om
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
