[ILUG] Re: contents of ILUG Digest, Vol 16, Issue 43

[Bill Stackpole]

--- Kenn Humborg <kenn at linux.ie> wrote:
> On Sat, Apr 10, 2004 at 08:21:03AM -0700, Bill
> Stackpole wrote:

<snip>

> To run this tool, the user already needs
> full
> read access (at a minimum) to the contents of the
> NTFS
> file system.  If they have this, all "potentially
> sensitive"
> files are already compromised.

***
Ken,
Your contention is true with respect to the person
actually IMPLEMENTING the change (e.g. that person
will already have read access to all files in
question.) However my position is based on the reasons
one might use an NTFS-based filesystem in the first
place - that is, to limit access to OTHER users on the
system. 

My contention is that *should* one translate the
contents from NTFS to FATxx and make the drive
available over the network (leaving the files in the
FATxx filesystem with no security controls) one might
enable the formerly-protected files to be accessed by
an unauthorized individual. Nuff said.
***

> > Further, the way the NTFS f/sys stores each of the
> > parts to a given file is through a series of
> > structures called "data streams" (the concept of
> which
> > doesn't lend itself to existence in a FAT-based
> > f/sys). 
> 
> This is true.
> 
> > A single file in an NTFS f/sys generally
> > contains the permission and ownership information
> in
> > one "stream", ...
> 
> But I really don't think this is true.
> 
> > ... the data content in another "stream",
> > while even more "streams" can exist (or be
> created) to
> > contain further data or information. 
> 
> AIUI, the ownership and permissions (i.e. the
> security descriptor
> for the file) are stored in the equivalent of the
> inode
> (i.e. the master file table entry for the file).
> 
> I've real quite a bit about the use of multiple
> streams in
> NTFS files in Microsoft documentation, yet I've
> _never_ seen
> them say that the security descriptor was stored in
> an 
> alternate stream).

***
I think this is a valuable discussion so I'm going to
elaborate...

I think our disconnect here is due to a disconnect
with respect to our interpretations of a "stream" in
NTFS. 

(Will you grant me that even Microsoft has a hard time
defining a "stream"? <grin>). 

I was pretty sure I had read that the MFT entry for a
file is accessible (for a "file open" command) via a
stream number. My logic is that if one is able to open
the metadata part of a file with a Microsoft
programming tool using a numerical value represented
in a stream-like format, one might consider that
metadata part of the file to be a stream-like
structure. Again, this is not something I have DONE,
it's something I have READ.
To resolve this particular question, lets ask for some
additional feedback:
OPEN REQUEST - Any programmers out there who have
direct experience reading/writing to NTFS streams -
and specifically the metadata stream - who might
address these questions? - END OPEN REQUEST

I will agree that NTFS uses a Master File Table (MFT)
to manage the permissions for each file. I will
further grant you that the MFT entry for a file
*could* be thought of as something similar to an inode
in UFS. However I believe this comparison to be
misleading and generally discourage such talk for the
following reason: If one compares the the MFT entry
for a file in NTFS and the inode in UFS, one will find
the existence of a FILENAME in the MFT which has no
such equivalent in a UFS inode. (All files in UFS are
referenced via their inode number, and the only place
I am aware where the name and inode number are related
is in a directory structure in UFS.) Since all
"streams" stored in NTFS are directly related back to
the original FILENAME (and it's named entry in the
MFT), I believe you could logically refer to that
location as a metadata stream, with all the alternate
file content locations (whether in the MFT, in the
file area of the disk, or in the "MFT zone" area) as
data streams (with the metadata stream being their
common denominator.)
***

> 
> > If a file in an
> > NTFS f/sys was to be simply copied to a FAT-based
> > f/sys, only the FIRST data "stream" is moved (the
> > remaining streams have no logical place to be
> stored
> > in a FAT-based system and as such, are lost.) 
> 
> There is nothing stopping such a conversion tool
> from
> converting the alternate streams to separate files
> on 
> the FAT filesystem, with a suitable naming
> convention
> such as FILE.EXT, FILE.EXT.STREAM2,
> FILE.EXT.STREAM3,...

*** 
I agree. You are correct - there is nothing to stop
one from creating files based on your naming
convention (or using some alternative.) To keep
everything straight, one would have to ensure an
intelligent and logical approach. 

I believe that prior to copying existing streams, one
would have to KNOW the data streams exist, AND know
their NAMES in order to copy them. (I'm willing to
accept corrections to this belief as well.)

What I was trying to say was that there's more to
creating a conversion tool than meets the eye.
*** 

> > I would be willing to bet that if you asked an
> equal
> > number of Sys-admins, folks involved in f/sys or
> OS
> > development, and computer security personnel, most
> of
> > those folks would tell you that it wouldn't be a
> good
> > idea to translate to FAT from NTFS, should any
> tools
> > actually be available to do so.
> 
> Well, I fall into all three of those camps you've
> mentioned
> and I have absolutely no objection to such a tool. 
> I wouldn't
> expect that an NTFS-to-FAT tool would necessarily
> allow
> round-tripping (i.e. convert to FAT and back to NTFS
> without
> losing information), but it would be possible if the
> security
> descriptors, alternate streams and other NTFS
> features were
> stored into additional files on the FAT fs.

***
Should have included here " ... wouldn't be a good
idea to translate from NTFS to FAT and make the
content available for general use again..."

Under certain VERY controlled conditions (e.g. it's my
server, or it's not available to any unknowns in my
organization) I might agree to conversion to a FATxx
filesystem. But the combination of time, effort, and
sacrifice in authentication / access controls, one
would have a very hard time convincing me to convert. 
***

> > BTW, If you get any alternative answers to your
> > question, I'd be interested to hear them (e.g.
> anyone
> > who knows of tools that would allow such a
> > translation.)
> 
> I think the difficulty with an NTFS-to-FAT
> conversion is
> doing it in-place.  AIUI, one of the design criteria
> in NTFS
> was in-place conversion from FAT, so the on-disk
> structures are
> layed out such that you can safely convert from FAT
> to NTFS.
> (It might not be an optimally-laid-out filesystem,
> but it works.)
> However, it is very possible that the layout
> requirements of
> FAT prevent a reliable conversion in the opposite
> direction.
> 
> This suggests that Partition Magic can do
> NTFS-to-FAT conversions
> but is not 100% reliable.
> 
>   
>
http://www.experts-exchange.com/Operating_Systems/Q_20695721.html
> 
> Later,
> Kenn
> 

*** Thanks for your comments and have a great day!
Bill. ***


__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html