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. > > 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. > > 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. > > > Regards, > > Olaf > > > > -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente