Difference (from prior major revision) (minor diff)

Paragraph 12		Paragraph 12
* SylStor stores more node metadata as attibutes than AFS does (eg the rwx bits and node type are no longer stored with the actual node itself, but as system attributes).		* SylStor stores more node metadata as attibutes than AFS does (eg the rwx bits [now ACLs] and node type are no longer stored with the actual node itself, but as system attributes).
		* SylStor directly supports "virtualised" attribute flagging and resolution.
* SylStor supports (read-only) caching of heavily-referenced attributes within the node itself.		* SylStor supports (read-only) caching of heavily-referenced attributes within the node itself.
Paragraph 17		Paragraph 18
* SylStor allows nodes to represent a directory <i>in addition to</i> other node-types (file-directory duality)		* SylStor allows nodes to represent a directory <i>in addition to</i> other node-types (file-directory duality)
		* SylStor permits multiple root blocks, allowing multiple directory trees to exist within the same volume & be mounted & manipulated independently.
* SylStor supports reporting of nodes with the advanced modes supported by the ReServ (such as cacheable status, listable status, etc)		* SylStor supports reporting of nodes with the advanced modes supported by the ReServ (such as cacheable status, listable status, etc)
Paragraph 22		Paragraph 24
<B><U><H2>SylStor on Syllable Classic:</H2></U></B>		<B><U><H2>SylStor implementation:</H2></U></B>
		<p>As of 25 July 2003, SylStor is functional, although still largely experimental. The following describes the features with which there are still known problems, or which are incompletely implemented:</p> <p>The compression functions do not, at present, check for size increases over blocks: the compression is "dumb", expecting the datacrypt module to do this kind of checking.</p> <p>File Obfuscation is still rather unreliable, with faulty block tracking (both of "false-used" blocks and actually obfuscated file-blocks). In addition, the current implementation allows a listing of the EIDs with (at least some) access to the node in question if the key used to encrypt the node itself is obtained. Individual entries are encrypted with keys specific to the EID of the entry, however.</p> <p>The current caching algorithm currently forces the caching of some attributes and appears to inefficiently allocate cache space or select attributes worth caching. Some tuning needs to be conducted.</p> <p>SylStor uses disk space rather inefficiently. Since some user & system attributes are compulsory and others are heavily used & applied by the system, and since each EID's ACE is stored in a separate attribute, SylStor has a very high metadata:data ratio. However this appears to be an inescapable side-effect of SylStor's design & purpose. For higher space efficiency (but lower security), AFS w/ACLs or FAT+AFS (a FAT driver similar to umsdos which uses .swdf files to track AFS-style metadata) is recommended.</p> <p>Some functions reporting to the ReServ currently have not been updated to account for dual attribute directories and are a known security hole in addition to causing problems with same-named attributes in separate directories, and inconsistently writing to either attribute directory.</p> <p>SylStor currently confuses some applications which do not understand file-directory duality, occassionally reporting the wrong "mode" (ie file vs directory) to the ReServ when asked for a legacy node-type. Under investigation</p> <p>SylStor "masquerade" format mode is semi-functional, although there are <i>many</i> bugs in the driver support - it is still very unstable. The same is true to a greater degree of "masquerade" mount mode (on a standardly formatted SylStor volume) - translation is very poor and inconsistent at present.</p> <B><U><H2>SylStor on Syllable Classic & other systems:</H2></U></B>
<p>The author plans to back-port SylStor to Syllable Classic at some point in the near future. However, since the design of the FS has long passed making simple modifications to the AFS driver, and since many parts of SylStor are dependant on SylSec for functioning (eg encrypted files/volumes) and Syllable Classic does not at present have the ability to support others (eg file-directory duality), such support will necessarily be limited.</p>		<p>The author plans to back-port SylStor to Syllable Classic at some point in the near future. However, since the design of the FS has long passed making simple modifications to the AFS driver, and since many parts of SylStor are dependant on SylSec for functioning (eg encrypted files/volumes) and Syllable Classic does not at present have the ability to support others (eg file-directory duality), such support will necessarily be limited.</p>

---

SyllableSecure (SylSec): The Syllable File Storage System (SylStor)

A Collection of RFCs detailing a security retrofit to the Syllable Operating System, including Access Control Lists, Security Labels, and Auditing.

---

SylStor Overview:

SylSec, and the file-referencing system that it brings along with it in the form of the ReServ, requires a relatively high-performance, specialized filesystem to operate efficiently and to take advantage of it's native capabilities. Features such as heavy attributing of nodes, file-directory duality, compression, encryption & obfuscation, 256-bit UEID ownership tracking, and (potential) high reliability, are not otherwise available all on a single filesystem, and especially not having a native Syllable- or ReServ- compatible driver. Although there are filesystems extant that could be bent to the task, such as ReiserFS v4, it seemed more expedient to simply modify the existing Syllable file system (a.k.a. AthFS or AFS) to support all this. Indeed, AFS already supported much of this, with strong support for extensible attributes and journalling + btree structure.

SylStor vs Atheos FS (AFS/AthFS):

SylStor differs from AFS in the following ways:

• SylStor supports two attribute directories per node (user and system) rather than the one of AFS.
• SylStor stores more node metadata as attibutes than AFS does (eg the rwx bits [now ACLs] and node type are no longer stored with the actual node itself, but as system attributes).
• SylStor directly supports "virtualised" attribute flagging and resolution.
• SylStor supports (read-only) caching of heavily-referenced attributes within the node itself.
• SylStor allows obfuscation of a node's vital information (the amount thereof varies according to settings) through meta-nodes within the filesystem pointing to the real node(s).
• SylStor expands the "owner" field and removes the "group" field altogether.
• SylStor supports ELinks natively.
• SylStor allows nodes to represent a directory in addition to other node-types (file-directory duality)
• SylStor permits multiple root blocks, allowing multiple directory trees to exist within the same volume & be mounted & manipulated independently.
• SylStor supports reporting of nodes with the advanced modes supported by the ReServ (such as cacheable status, listable status, etc)
• SylStor increments the AFS partition type by 1
• SylStor allows many of it's features to be preset as both format and mount options, allowing it to "masqerade" as a traditional AFS partition.

SylStor is, at present, untested as regards speed differences versus AFS. Although no serious differences have yet been detected, tests and optimization must occur in the future. It is thought, however, that since the ReServ allows the FS driver to do much of the "work" involved in file access to a SylStor volume, whereas some translation is required by the ReServ in the case of AFS volumes, that SylStor should outperform AFS slightly on a SylSec setup. With more traditional native-mounting, the author refrains from hazarding a guess :)

SylStor implementation:

As of 25 July 2003, SylStor is functional, although still largely experimental. The following describes the features with which there are still known problems, or which are incompletely implemented:

The compression functions do not, at present, check for size increases over blocks: the compression is "dumb", expecting the datacrypt module to do this kind of checking.

File Obfuscation is still rather unreliable, with faulty block tracking (both of "false-used" blocks and actually obfuscated file-blocks). In addition, the current implementation allows a listing of the EIDs with (at least some) access to the node in question if the key used to encrypt the node itself is obtained. Individual entries are encrypted with keys specific to the EID of the entry, however.

The current caching algorithm currently forces the caching of some attributes and appears to inefficiently allocate cache space or select attributes worth caching. Some tuning needs to be conducted.

SylStor uses disk space rather inefficiently. Since some user & system attributes are compulsory and others are heavily used & applied by the system, and since each EID's ACE is stored in a separate attribute, SylStor has a very high metadata:data ratio. However this appears to be an inescapable side-effect of SylStor's design & purpose. For higher space efficiency (but lower security), AFS w/ACLs or FAT+AFS (a FAT driver similar to umsdos which uses .swdf files to track AFS-style metadata) is recommended.

Some functions reporting to the ReServ currently have not been updated to account for dual attribute directories and are a known security hole in addition to causing problems with same-named attributes in separate directories, and inconsistently writing to either attribute directory.

SylStor currently confuses some applications which do not understand file-directory duality, occassionally reporting the wrong "mode" (ie file vs directory) to the ReServ when asked for a legacy node-type. Under investigation

SylStor "masquerade" format mode is semi-functional, although there are many bugs in the driver support - it is still very unstable. The same is true to a greater degree of "masquerade" mount mode (on a standardly formatted SylStor volume) - translation is very poor and inconsistent at present.

SylStor on Syllable Classic & other systems:

The author plans to back-port SylStor to Syllable Classic at some point in the near future. However, since the design of the FS has long passed making simple modifications to the AFS driver, and since many parts of SylStor are dependant on SylSec for functioning (eg encrypted files/volumes) and Syllable Classic does not at present have the ability to support others (eg file-directory duality), such support will necessarily be limited.

The author is also looking into a possible IFS driver for Windows NT 4.0/2000, which might allow greater support for some SylStor features. Since many parts of SylStor were inspired by NTFS features, this looks to be an appropriate platform to support SylStor outside of SylSec. In addition, NT 4.0/5.x provide some level of cryptographic and security support for the SylStor driver to "lean" on. It is though that AFS support would more than likely be included with such a driver or written in parallel.

Although the possibility of supporting SylStor features via Reiser v4 plugin(s) has been raised with the author, no plans have been made to write such plugin(s) at this time.

Back to Main page