Re: Some thoughts about extensions and mime types

[Olaf Frączyk <olaf cbk poznan pl>]

On Wed, 2004-02-04 at 20:55, Manuel Amador (Rudd-O) wrote:
> Your proposal, although having good goals, is flawed in its foundation. 
> The threat model you're trying to deflect doesn't match the threat model
> you're attacking in practice.
> 
> I already stated the problem with extensions are:
> * confusion on the end user
> * wrong actor placement of the responsibility of file typing
> 
> The creator applications should have the responsibility of marking files
> with their type.  If you have a bad app, since it's assumed your admin
> or you installed it, it's your responsibility then.
> 
> What you're asking for is some sort of passive malware detector.  Your
> FTD would actually introduce larger problems, because it runs as root.
> 
> See below:
> 
> El mar, 03-02-2004 a las 05:36, Olaf Frączyk escribió:
> > Hi,
> > What I understand from previous mails is that we need robust and safe
> > file type detection.
> > So I think:
> > It doesn't matter if type is putted as extension or inside of file. Both
> > can be changed by attacker or virus creator. And simple sniffing can be
> > fooled, too.
> > So I don't think that tagging a file with a file-type by application is
> > good solution. It has the same flaws as tagging with file extension.
> 
> Not at all.
What is the difference where you place file description? In extension,
or inside the file?
> > 
> > To have secure type-file detection we need File Type Detector (FTD) on
> > local computer. It has to be run as root to be able to read all files.
> > It has to examine every file and such examination has to be really
> > reliable (much more that sniffing today). FTD has to maintain secure
> > database. In such database we need: filename (full path), mtime, ctime,
> > filetype.
> > When a file is examined DFT will put in this database these data, so we
> > will know if a file was changed after it was examined.
> > The database can be:
> > - external - any kind of database optimized for this task
> > - internal - this requires changes in filesystem. But it would be the
> > fastest solution, I think. What I mean here, would be adding a secure
> > (writable only by root) space in directory (similar to that one which
> > currently contains filenames in directories, but is not secure).
> 
> You're asking for reimplementation of Extended Attributes (EAs), but
> with lots and lots of dangers, and a flawed approach.  Since you're
> extracting data about data, the logical place where they belong is
> *along* the data, not in a separate database.
What I proposed here is fast and secure file type detection. And EAs are
not OK for it. Even if you had a secure space in EA (AFAIR XFS has),
then the access is too slow. If it was placed in directory, you get it
with one open and one seek.
> 
> > 
> > Then if we want to open a directory from filemanager we would just check
> > (for every file) the database if the file has file type description, and
> > if it is out of date or it is not present, we would ask FDT to check
> > this file. With internal (in directory) database it should be as fast as
> > normal directory opening.
> > 
> > The real problem is when opening file by application. There is always a
> > risk, that somebody has changed content of the file, just between we see
> > it in nautilus and before the application opened it.
> > The only solution for this problem I can think, is mandatory locking for
> > writing. An application opens file, locks it for writing, asks DFT if
> > the file type is still valid (not out of date), if not, it asks DFT to
> > re-examine this file.
> 
> This is definitely not the UNIX way.  EAs already have transaction
> atomicity.
But they are not usable (too slow) for this.
> > 
> > 
> > Regards,
> > 
> > Olaf
> > 
> > 
> > 
> > 
> -- 
> 	Manuel Amador (Rudd-O)
> 	GPG key ID: 0xC1033CAD at keyserver.net