Re: [cti] Re: Common CybOX Object Refactoring

["Kirillov, Ivan A." <ikirillov@mitre.org>]

>I was reviewing this, and hit the FileMismatchEnum part...  What do
>you do when you have a file that is a PNG w/ a ZIP file added at the
>end...  no mater which mime-type you pick, image/png or
>application/zip, there will be a mismatch... and it'll mismatch on all
>three: magic, extension and type..



I don’t think there’s anything wrong with specifying all three mismatches in this case - the multiplicity of the “mismatch-type” field is unbounded, so it’s perfectly valid to do that.

>We should probably not name this EXT3FileExtension, because that means
>that UFS file systems "can't" use it, or it give misleading
>information...  It could possibly be renamed UFS, as EXT was inspired
>UFS, though I'm open to other suggestions...

Ah, good point. I’m fine with calling it UFS for accuracy; the EXT3 extension could then be a subclass of UFS.

>There is also no support for extended attributes...  This should
>be added, as MacOSX makes heavy use of extended attributes to
>record information like where a file was downloaded from, and if it
>is allowed to be open w/o a security warning or not...


It does seem like it would be useful to capture these. Do you know if there are any “default” extended attributes? From my brief reading this morning, it appears that they’re essentially name/value pairs. Also, I wonder if these should be captured in the basic file system properties class (FileSystemProperties), or as an extension.

>I would say that the field name for the hash type should not be named
>type, otherwise it could be confused w/ the TLO type field.  Maybe
>algo instead of type?

Agreed. How about “hash_type”? There’s already a “hash_value” field, so it would fit well.

Regards,
Ivan





On 2/22/16, 1:04 PM, "cti@lists.oasis-open.org on behalf of John-Mark Gurney" <cti@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote:

>Kirillov, Ivan A. wrote this message on Mon, Feb 22, 2016 at 15:36 +0000:
>> File Object
>>      *   Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring
>>      *   Open questions:
>
>I was reviewing this, and hit the FileMismatchEnum part...  What do
>you do when you have a file that is a PNG w/ a ZIP file added at the
>end...  no mater which mime-type you pick, image/png or
>application/zip, there will be a mismatch... and it'll mismatch on all
>three: magic, extension and type..
>
>>         *   Are there any additional properties that belong in the base set of properties or basic set of file system properties?
>>            *   Current consensus: no additional properties have been raised.
>>         *   Which default extensions should be included with the Object?
>>            *   Current proposed list:
>>               *   File Metadata
>>               *   EXT3 File
>
>We should probably not name this EXT3FileExtension, because that means
>that UFS file systems "can't" use it, or it give misleading
>information...  It could possibly be renamed UFS, as EXT was inspired
>UFS, though I'm open to other suggestions...
>
>There is also no support for extended attributes...  This should
>be added, as MacOSX makes heavy use of extended attributes to
>record information like where a file was downloaded from, and if it
>is allowed to be open w/o a security warning or not...
>
>I would say that the field name for the hash type should not be named
>type, otherwise it could be confused w/ the TLO type field.  Maybe
>algo instead of type?
>
>-- 
>John-Mark
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that 
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>