Faculty of Health, Science and Technology Master thesis in Computer Science Second Cycle, 30 hp (ECTS)
Supervisor: Leonardo A. Martucci, University of Karlstad, SWE <leonardo.martucci@kau.se>
Examiner: KarlJohan Grinnemo, University of Karlstad, SWE <karljohan.grinnemo@kau.se>
Karlstad, June 6th, 2021
Classification Storage
A practical solution to file classification for information security
En praktisk lösning till fil klassificering för informationssäkerhet
Joël Sloof <joelsloof@gmail.com>
Abstract
In the information age we currently live in, data has become the most valuable resource in the world. These data resources are high value targets for cyber criminals and digital warfare. To mitigate these threats, information security, laws and legislation is required. It can be challenging for organisations to have control over their data, to comply with laws and legislation that require data classification. Data classification is often required to determine appropriate security measured for storing sensitive data.
The goal of this thesis is to create a system that makes it easy for organisations to handle file classifications, and raise information security awareness among users. In this thesis, the Classification Storage system is designed, implemented and evaluated.
The Classification Storage system is a Client–Server solution that together create a virtual filesystem. The virtual filesystem is presented as one network drive, while data is stored separately, based on the classifications that are set by users. Evaluating the Classification Storage system is realised through a usability study. The study shows that users find the Classification Storage system to be intuitive, easy to use and users become more information security aware by using the system.
Keywords
Data Classification, Information Classification, UserDriven Classification, Information Security Awareness
Sammanfattning
I dagens informationsålder har data blivit den mest värdefulla tillgången i världen.
Datatillgångar har blivit högt prioriterade mål för cyberkriminella och digital krigsföring. För att minska dessa hot, finns det ett behov av informationssäkerhet, lagar och lagstiftning. Det kan vara utmanande för organisationer att ha kontroll över sitt data för att följa lagar som kräver data klassificering för att lagra känsligt data.
Målet med avhandlingen är att skapa ett system som gör det lättare för organisationer att hantera filklassificering och som ökar informationssäkerhets medvetande bland användare. Classification Storage systemet har designats, implementerats och evaluerats i avhandlingen. Classification Storage systemet är en Klient–Server lösning som tillsammans skapar ett virtuellt filsystem. Det virtuella filsystemet är presenterad som en nätverksenhet, där data lagras separat, beroende på den klassificeringen användare sätter. Classification Storage systemet är evaluerat genom en användbarhetsstudie. Studien visar att användare tycker att Classification Storage systemet är intuitivt, lätt att använda och användare blir mer informationssäkerhets medveten genom att använda systemet.
Nyckelord
Dataklassificering, Informationsklassificering, Användardriven Klassificering, Informationssäkerhet Medvetenhet
Acknowledgements
I would like to thank and acknowledge all the people at Veriscan for introducing me to the field of information security. Their experience and guidance, motivated me to pursue a career in information security and inspired me to create the Classification Storage system.
My family has always supported me in my ventures and that includes this one. I would like to thank my parents and siblings for supporting me and my crazy ideas in life and in this project.
Special thanks goes to my fiance Matilda for her love, support and for always believing in me.
Contents
1 Introduction
11.1 Thesis Goals and Results . . . 2
1.2 Methodology . . . 2
1.3 Ethics and Sustainability . . . 3
1.4 Thesis Outline . . . 4
2 Background and Related Work
5 2.1 WebDAV . . . 62.2 Middleware . . . 6
2.3 Bit Field . . . 7
2.4 Filesystem in Userspace . . . 7
2.5 Windows Shell Extension . . . 8
2.6 Sticky Policies . . . 8
2.7 Microsoft 365 . . . 9
2.8 Summary . . . 9
3 System Architecture
11 3.1 Classification Storage . . . 113.1.1 File Storage . . . 13
3.1.2 Server / Virtual Storage . . . 13
3.1.3 Clients . . . 13
3.2 Server Architecture . . . 14
3.2.1 Sabre/DAV . . . 15
3.2.2 Authentication Module . . . 15
3.2.3 Virtual Filesystem . . . 15
3.2.4 Server API . . . 16
3.3 Client Architecture . . . 16
3.3.1 Client (FUSE) . . . 17
3.3.2 Windows FUSE Module . . . 18
3.3.3 Classification Service . . . 18
3.3.4 Classification Module . . . 19
3.4 Summary . . . 19
4 System Implementation
20CONTENTS
4.1 Server . . . 20
4.1.1 Sabre/DAV . . . 22
4.1.2 Virtual Filesystem . . . 23
4.1.3 Classification Plugin . . . 24
4.2 Client . . . 26
4.2.1 CSFS . . . 27
4.2.2 CSShellExtension . . . 29
4.2.3 CSDialogBox . . . 31
4.3 Summary . . . 32
5 System Evaluation
34 5.1 Usability Study . . . 355.1.1 Part One: Interview . . . 35
5.1.2 Part Two: Experiment . . . 35
5.1.3 Part Three: Post Experiment Interview . . . 38
5.2 Recruitment and Participants . . . 39
5.3 Ethical Considerations . . . 39
5.4 Data Analysis . . . 40
5.5 Results . . . 43
5.6 Limitations . . . 44
5.7 Summary . . . 45
6 Discussion
46 6.1 Classification Storage . . . 466.2 Evaluation Results . . . 47
6.3 Limitations . . . 48
6.4 Summary . . . 49
7 Conclusions
50References
52Chapter 1 Introduction
Throughout history, information has always been an important asset and with the invention of information technology systems (IT systems) and the digital evolution, these assets have evolved to becoming the most valuable resource in the world [37].
The rapid development and adoption of IT and communication systems have changed the world through a digital revolution leading to the current information age [7].
Organisations all over the world are constantly collecting and processing more and more data to analyse and use to their benefit [43]. With data being as valuable as it is and organisations and systems being interconnected across the world, data has become a high value target for cyber criminals and digital warfare [13, 20]. These threats require mitigation in the form of information security, legislation and laws. Legislation and laws are not only focused on the protection of data but also on regulating unlawfully acquired data, preventing organisations from breaching privacy laws and protecting users.
For organisations to be compliant with legislation and laws, adequate controls need to be implemented to ensure that sensitive data is secure at all times. Two examples of such controls are ISO 27001 Annex: A.8.2.1 Classification of Information and Annex:
A.8.2.2 Labeling of Information [1]. A.8.2.1 is about securing information according to its significance. A.8.2.2 is about labeling information following a classification scheme or policy for an organisation. These types of controls can be challenging to implement on unstructured data such as Worddocuments and other files. File classification and labeling of this type of unstructured data, enhances information security and governance [36].
Information security awareness is an important part of information security and information security awareness training has proven to enhance security for organisations [9]. Data classification tools can be used for file classification to enhance information security and comply with legislation and laws. Data classification tools and systems do not only improve information security and identifiability of data, but also raises awareness among users of their responsibilities in protecting the data [36].
CHAPTER 1. INTRODUCTION
This thesis explores if a system can be created, where users set classifications and labels when working with files directly. The system should also store files separately depending on classification levels.
1.1 Thesis Goals and Results
The goal of this thesis is to design, implement and evaluate a system that allows users to perform file classifications.
The system should be able to store files separately based on classification to allow for appropriate security measures to be applied for each classification level. To users, this distributed storage system should be presented as one network drive for ease of use. By making users set classifications and/or labels on files before saving them to the network storage, the goal is to both achieve user driven classification and raise awareness of information security.
From a user perspective, the system should be intuitive, easy to use and make it easy to follow company information security classification policies. A system that makes users more information security aware and makes it easy to follow company policies, should result in accurate classifications and a change in user behaviour to the benefit of information security.
The system that is designed and implemented in this thesis consists of a server and a client that together create a virtual filesystem. This virtual filesystem makes users set a classification on a file when the file is saved. File interaction is sent to the server with its classification as metadata throughout the process. The server analyses the metadata and stores the classified file in a location matching the classification of the file. This allows for a higher level of security to be applied on files with classifications that require this. The system is called Classification Storage and achieves the goals set for the system. The Classification Storage system is evaluated through a usability study.
The study shows that users find the Classification Storage system to be intuitive, easy to use and users become more information security aware by using the system.
1.2 Methodology
This thesis explores if a system can be created where users set classifications and labels when working with files directly. Can a system like this improve user awareness of information security and make it easier for users to follow company policies?
Answering this question is accomplished by creating and testing the system. The thesis work is realised in three steps: design, implementation and evaluation.
CHAPTER 1. INTRODUCTION
Firstly, a system is designed that achieves the technical thesis goals. Secondly, the system architecture is used to develop the Classification Storage system. The final implementation of the Classification Storage system is slightly different from the System Architecture. These changes are found to be better solutions than the architecture describes and some modules were not implemented because of time restrains.
Lastly the Classification Storage system is evaluated through a usability study. The usability study is performed through experiments and interviews with participants.
The Classification Storage system is depending on users to set file classifications and tags. Therefore, the system is required to be intuitive and user friendly, and is evaluated using the Nielsen’s heuristics [27], which is commonly used to evaluate user interface design. Furthermore, one of the thesis goals is to evaluate, if the Classification Storage system makes users more information security aware. Those requirements and goals make a usability study the best method for evaluating the system. Participants gain experience using the system through experiments, followed by interviews that establish the findings of participants. Through this evaluation we can conclude if the created system improves user information security awareness and if participants find that this system would make it easier to follow company policies.
1.3 Ethics and Sustainability
In the thesis work, a system is created that is used to classify files and data, following organisational policies and rules. The process of file and data classification is an ethical dilemma, where policies can reflect social values [5]. The rules and policies that are applied to data classification, are created by humans with their judgement and social values [35]. This causes the ethical discussion surrounding data classification to be closely connected to ethical values in society.
The Classification Storage system impacts society by supporting organisation to store sensitive data securely and making users more information security aware. This easy to used system could make it compelling for more organisations to start following information security standards. The Classification Storage system can be used as a tool to follow laws and legislation. This is however, very dependent on the way an organisation integrates the system. The Classification Storage system is designed to be customisable, to support organisational policies. If an organisation would want to store and classify data unethically, then this system could probably also be implemented and utilized to support that.
CHAPTER 1. INTRODUCTION
Information classification is a key part of information security, to protect sensitive data.
Protecting data is not only important from an organisational perspective but also as a consumer. Evermore regulations such as GDPR are imposing legislation on data handling and storage, requiring organisations to classify their data. The motivation for creating the Classification Storage system, is to make it easier for organisations to comply with controls imposed by laws and legislation. Organisations can raise information security and help prevent incidents, by utilising the Classification Storage system.
1.4 Thesis Outline
This thesis focuses on the Classification Storage system that is designed, implemented and evaluated. First, the background is explained and discussed in Chapter 2. The system architecture is described in Chapter 3. From the system architecture, the Classification Storage system is developed. The implementation of the Classification Storage system is described in Chapter 4. The Classification Storage system is evaluated through a usability study that is described in Chapter 5. Discussions about the final system along with results and limitations are discussed in Chapter 6. Lastly, the conclusion of the thesis work and future works are covered in Chapter 7.
Chapter 2
Background and Related Work
This chapter discusses and explains concepts, solutions and related work, that are of importance to the system created in this thesis work. The system is a Client–Server solution implemented using different software solutions, techniques and protocols.
Some of the software solutions, techniques and protocols require further clarification before they are discussed in the System Architecture and System Implementation Chapters 3 and 4.
This chapter is organized as follows. Sections 2.1–2.5 introduce the communication protocol, techniques and framework used in the implementation of our solution.
Sections 2.6 and 2.7 present the related work.
The communication protocol WebDAV is explained in Section 2.1. This protocol is used for all communication between the client and the server. Sections 2.2 and 2.3 explain two techniques, middleware and bitfields. These are used in the implementation of the server. Sections 2.4 described a framework that is used to create a filesystem in the client and Section 2.5 explains what Windows shell extensions are and how the client integrates with Windows.
Sections 2.6 and 2.7 describe two related solutions. These solutions both have similarities and partially provide the same functionality that the system proposed in this thesis aims to achieve. Sticky policies are described in Section 2.6 and Microsoft 365 is described in Section 2.7. Lastly, Section 2.8 summarizes the chapter.
CHAPTER 2. BACKGROUND AND RELATED WORK
2.1 WebDAV
SabreDAV is a PHP implementation of Web Distributed Authoring and Versioning (WebDAV) that is used for Client–Server communication [12]. The Sabre/Dav code is extended with a virtual filesystem layer. The combined codes runs on a webserver that functions as a file sharing server for a local network.
WebDAV is a protocol that extends the Hypertext Transfer Protocol (HTTP). The WebDAV protocol allows clients to manage file properties, create files, create collections (folders) and implements a locking system to prevent collisions between clients [16].
This protocol is defined by the Internet Engineering Task Force (IETF), a nonprofit organisation that develops internet standards [39]. WebDAV has a wide range of extensions that further enhance the capabilities of the protocol, such as access control, calendar sharing, contact information sharing, extended collection management and many more [14, 15, 17, 38].
2.2 Middleware
For this thesis, middleware is used on the server to handle classification and tag metadata as described in Section 4.1.3. Middleware is software that is used as a middle layer between applications and is often used to manage data in distributed applications [31]. Through the use of middleware applications can for example, be made compatible by altering input and output data structures. Middleware can also be used to describe database connection software and is also often used with Web APIs as seen in Figure 2.2.1.
Figure 2.2.1: Middleware: The request and response both pass through the middleware before reaching the API and Client. This way, data can be restructured or certain behaviours can be achieved without the need to change the client or application API.
CHAPTER 2. BACKGROUND AND RELATED WORK
2.3 Bit Field
Bit Fields are data structures that represent a group of Boolean values that are also known as binary bit flags. Binary bit flags are used in this thesis when tags are stored and used as described in section 4.1.3. A 1 represents true and 0 represents false. These Boolean values are grouped together into a single integer as seen in Table 2.3.1
int Bit Value Boolean Value
0 0 false
1 1 true
2 10 true , false
3 11 true , true
4 100 true , false , false 8 1000 true , false , false , false
Table 2.3.1: Integer values represented as bit values and Boolean values.
This means that many Boolean values can be stored in one integer value. The value of a specific Boolean can be calculated with a simple bitwise operation as seen in Figure 2.3.1.
1 # define TAG_ONE 1 // 1
2 # define TAG_SEVEN 64 // 1000000
3
4 if (( flags & TAG_ONE ) != 0) // tag one is set
5 if (( flags & TAG_SEVEN ) != 0) // tag seven is set
Figure 2.3.1: Example code showing how to see if bit flags are set or not.
2.4 Filesystem in Userspace
The target audience for the Classification Storage client, is assumed to be Windows users and therefore a Windows implementation is decided on for our work. The Classification Storage client is developed with an implementation of the Filesystem in Userspace (FUSE) framework for Windows called WinFsp [42].
FUSE is a framework in the Linux kernel with which the development of virtual file systems in userspace can be achieved [40]. In most operating systems, userspace is a part in memory where applications are executed, while kernelspace is a more restricted and privileged part of memory where mostly hardware drivers are executed.
Filesystem code in an operating system is executed in the privileged kernelspace making customizing filesystems a challenging task. FUSE allows for nonprivileged users to create virtual filesystem without the need to modify any kernel code.
FUSE systems have been ported to many different operating systems [2, 10, 11, 42].
Allowing for the creation of a virtual filesystem following the FUSE principles and allows for easy porting of the project to other platforms that support FUSE.
CHAPTER 2. BACKGROUND AND RELATED WORK
2.5 Windows Shell Extension
Windows shell extension is used in the CSShellExtension of the client as described in Section 4.2.2. The handlers used in CSShellExtension are icon overlay handlers and a context menu handler.
The Windows shell is the GUI of Windows. The shell has a close relation to the Windows file explorer that is used to browse files and directories, launch the start menu and desktop, file type associations and many other Windows features [41].
Windows shell extensions are extensions to the Windows shell through registry entries and.ini files. These extensions can be seen as plugins to Windows file explorer. These extensions are often implemented by using shell extension handlers. These handlers are called before shell actions are performed giving them the chance to change the behaviour of the shell [25].
2.6 Sticky Policies
The sticky policy paradigm is an attempt to allow restrictions and permissions to be directly attached to data. Sticky policies were first proposed in 2002, and have since mainly been used in fields such as cloud computing and internet of things networks [18, 26].
The goals of sticky policies are to regulate permissions throughout the life cycle of the data and be able to distribute the data across multiple organisations following predetermined principles. This allows users to have more control over their data. The principles that are attached to the data would have strict rules as to how the data could be used and by whom. The rules that apply to the data would always need to be followed by the systems having access to the data, and this is one of the challenges with sticky policies. The paradigm only works if all the systems that have access to the data follow the privacy rules or the integrity of the entire system fails. This could be the reason that sticky policies have seen implementations in fields such as cloud computing and internet of things. These fields are relatively closed ecosystems with the control to enforce compliance with the policies and rules set on data [26].
With the use of sticky policies, it would seem a natural step to implement file classifications. These classifications could be attached by users and further encryption could also be implemented on those files that require this.
Sticky policies have many overlapping features with the goals of this thesis. However, the main difference in approach is that sticky policies requires the policies to be followed by any system that has access to the data. This thesis aims is to create a virtual file system that allows for classifications and tags to be set directly on a file.
This is controlled by Client–Server setup that enforces no further restrictions on other systems using the data.
CHAPTER 2. BACKGROUND AND RELATED WORK
2.7 Microsoft 365
Microsoft 365, better known as Office 365 is an office software suite that provides a wide range of products and services. These products and services are mainly cloud
based productivity solutions for businesses such as Word, Excel, PowerPoint and Outlook [23].
Microsoft 365 offers many features in regard to information protection and governance.
These features range from manual labeling of files to automated pattern matching for classification. These features are possible through the use of cloud technologies and the relatively closed ecosystem that files live in, only interacting with software in the same suite or through the Microsoft Information Protection SDK [22, 24].
The sensitivity labels feature of Microsoft 365 allows labels to be set on files that are used in the office suite. These labels can be set to enforce restrictions, encryption and permissions on a perfile bases, achieving userdriven classification.
The main difference between Microsoft 365 and the solution this thesis is exploring, is that Microsoft 365 relies on cloud techniques whereas the system in this thesis aims to achieve this in a distributed local storage solution. Furthermore Microsoft 365 is limited to the the office suite and the filetypes associated with it.
2.8 Summary
This thesis aims to design, develop and evaluate a system that allows users to perform file classifications in a distributed storage system. This chapter explained a few software solutions, techniques and protocols that are used in the implementation of the Client–Server solution that was developed. Further more, two related solutions with similar functionality, were discussed, compared and shortcomings were identified.
The Client–Server solution that is developed in this thesis makes use of the WebDAV protocol for its communication needs. Middleware is used in the server implementation to handle classification and tag metadata. The server also makes use of bit fields for storing and communicating tag metadata. The client is developed using a FUSE framework to create a filesystem. Windows shell extensions are used to integrate additional functionality to this filesystem in Windows to allow users to set classifications on files.
Setting classification or labels on files can be achieved with Sticky policies or Microsoft 365. These solutions can partially achieve the same functionality as the thesis goals.
Nonetheless, these solutions also have shortcomings that the system designed in this thesis aims to overcome. The sticky policies paradigm requires all connected systems to follow file policies and restrictions. Therefore, files in a system like that can only be used for purposes explicitly allowed by file policies, creating a closed environment.
Whereas the Client–Server solution that is developed in this thesis aims to be an
CHAPTER 2. BACKGROUND AND RELATED WORK
open environment allowing for other systems to interact with the data without further restrictions. Microsoft 365 offers userdriven file classification through labeling of files in there cloudbased productivity solutions. These labels can be used to enforce file classification restrictions, permissions and encryption. These features all rely on cloud techniques whereas this thesis aims to achieve these without dependencies of cloud techniques. The following chapter describes the system architecture that was found to achieve the goals of this thesis and overcome the previously mentioned shortcomings of other solutions.
Chapter 3
System Architecture
This chapter describes and explains the architecture that achieves the goals of this thesis. This work started during a previous course, Research Project in Computer Science (DVAE07). Most of the architecture was designed during that course, allowing for more time to implement the system during this thesis work.
The goal of this system is to allow users to perform file classification in a distributed storage system. To the user this should be presented as one network storage for simplicity and ease of use. This system also aims to raise awareness of information security among users. This creates the demand for an easy to use and intuitive system to successfully involve users more closely with file classifications.
Firstly, the entire system and its components are described in Section 3.1, along with design decisions that were made. Secondly and thirdly the server and client are described in more details in Sections 3.2 and 3.3. Lastly, the chapter is summarised in section 3.4.
3.1 Classification Storage
The architecture that is proposed to achieve the goals in this thesis consists of a Client–Server solution as seen in Figure 3.1.1. This section explains the role of the three main components of the system, how they communicate and the design choices that were made. After that the different components are described in more detail in Sections 3.1.1, 3.1.2 and 3.1.3.
The server connects with storage solutions that represent the different desired classifications. These storage solutions are combined to one virtual drive and is shared over a local network. Clients can connect to the shared network storage and request classifications and tags from user input before writing to the virtual storage. The classifications and tags are sent to the server using metadata appended to the chosen protocol.
CHAPTER 3. SYSTEM ARCHITECTURE
Figure 3.1.1: Classification Storage Architecture. An overview of the Client–Server layout and connections. The Server creates a virtual storage from the multiple different storage devices and servers. This virtual storage is used by the clients to create a virtual file system for the users.
WebDAV, as described in Section 2.1, was analysed and decided on, to be used as communication protocol. WebDAV includes file locking and supports HTTPS for added security. Sabre/Dav is a WebDAV server software that can be used as a basis to work from where custom modules can be added. These modules can achieve the modifications needed to communicate classifications and tags between the clients and server.
Different data transfer protocols that could be used in this design were analysed and compared. During the process of choosing a data transfer protocol, the following protocols and approaches were considered but discarded:
• SMB protocol,
• Secure Copy Protocol (SCP),
• SSH File Transfer Protocol (SFTP)
• rsync.
The SMB protocol was looked at because of its implementation in Windows and because the assumed users of this product are Windows users. Some time was spent investigating a potential implementation using SAMBA with a custom virtual file system module [30]. This solution was ruled out because of the difficulty of implementation and licensing.
CHAPTER 3. SYSTEM ARCHITECTURE
The following network file copy protocols were considered: Secure Copy Protocol (SCP), SSH File Transfer Protocol (SFTP) andrsync [29, 32, 33]. These protocols all have the same shortcomings in relation to this project. These shortcomings can be summarised to requirements of handling multiple clients at the same time and these protocols do not handle file locking to prevent collisions.
3.1.1 File Storage
The file storage servers or drives are separated by classification. These different classifications are determined by the organisations requirements and are not part of this research. The File storage servers share a network drive with the server or local drives are used for classifications. This way the system guarantees that files with different classifications are stored separately. This is desirable, because different classifications can require different levels of security.
3.1.2 Server / Virtual Storage
Files of different classification levels are stored on different file storage solutions, that are connected to the server. These storage solutions are mounted and used to store and get files of the corresponding classifications. The server creates a virtual file system combining all the connected storage solutions. This virtual file system contains all the files of different classifications with additional metadata of the classifications, tags and restrictions of the file.
Clients that connect to the virtual storage are required to send classification metadata with requests, to ensure that the file being processed is stored on the proper level of security following its classification. All requests also require user authentication data to ensure that only allowed files or levels of classification are accessible. The connection protocol used is WebDAV with additional metadata in the client requests and server responses.
3.1.3 Clients
Clients connect to the virtual storage with custom client software using an extended WebDAV protocol. This client makes use of custom metadata to pass different classification data to the server. The connections to the virtual storage is based on the authorisation level of the user, where only certain roles can acquire read and write rights for a given classification level. The client is designed for Windows because the target audience for this system is assumed to be Windows users.
CHAPTER 3. SYSTEM ARCHITECTURE
3.2 Server Architecture
The server architecture is dependent on four main modules that run on a web server as seen in Figure 3.2.1. This section first describes how the modules are connected and design choices. After that the different modules are described in more detail in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.4.
Figure 3.2.1: Server Architecture. All server modules and how they interact within the server. An Apache web server is the basis for the server software. On the web server the Sabre/DAV WebDAV software is running with three additional modules that together handle the all logic and communication with the clients.
Ubuntu 20.04 was selected as the server OS because of its high customizability and the authors preexisting Linux server knowledge [6]. Apache is used as the web server.
The web server implements the HTTP protocol in combination with many different modules that expand its functionalities. For our work the mod_php module is used to support the PHP serverside programming language required by Sabre/DAV.
The server connects to the local and network storage solutions using tools available in the operating system. The different storage locations represent the different classifications and are set in a config file for the virtual filesystem. The Sabre/DAV module is installed on top of the Apache web server and an authentication module is added. A virtual filesystem module and server API are created using the Sabre/DAV framework to implement the WebDAV protocol with extended functionality to allow file classification and tag metadata. The server API is used to handle all client communications.
CHAPTER 3. SYSTEM ARCHITECTURE
3.2.1 Sabre/DAV
The Sabre/DAV module is a PHP implementation of the WebDAV server protocol. This module functions as the framework for all the Client–Server communication. The following three modules are extensions to this WebDAV server implementation.
3.2.2 Authentication Module
The authentication module authenticates clients and displays the correct data according to the classification and authentication level that the client is connected with. The server has configurable features, e.g., file accessibility levels and requests for temporary elevated accessibility. Higher classification level files that are not permitted to be read by certain clients are displayed as empty (0 byte) files as seen in Figure 3.2.2.
These empty files have an option to gain temporary access after a request is granted by the data owner as seen in Figure 3.2.3.
Figure 3.2.2: Get File Access Flow. First, the request is checked for access through authentication. If the user sending the request is authorized, the requested file is returned. For unauthorized users the tag file is checked if the user has a temporary granted access tag. Users with temporary access receive the requested file and users without access receive an empty file.
3.2.3 Virtual Filesystem
The virtual filesystem module controls where a file is stored and what classification applies to a file that is read. All the storage locations that are connected are merged into one virtual file storage, where all files have classification and tag metadata. All the file operations that a client can perform on the virtual file storage are handled in the virtual filesystem.
CHAPTER 3. SYSTEM ARCHITECTURE
Figure 3.2.3: Temporary Access Request Flow. The temporary access request is send to the server from a user that needs access to a file that is above its authorization level.
This request is send to the Data Owner by Email. The Data Owner can add a temporary user token to the requested file’s tags to allow temporary access.
• Read operations make sure that the file is read from the correct path on the correct storage location and returned with the corresponding classification and tag metadata.
• Write operations make sure that files are written to the correct storage location matching the file classification.
• Classification changes are translated to moving files from one storage location to another.
3.2.4 Server API
The server API module uses the WebDAV protocol and extends its functionality to communicate the classifications and tag metadata to the clients. The clients connect to the server API with file operation requests. After getting verified by the authentication module, the file operation requests are handled by the virtual filesystem module that uses the server API to reply to the client requests.
3.3 Client Architecture
To achieve the desired functionalities, the client makes use of a FUSE implementation for Windows, along with three other modules to create a virtual filesystem as seen in Figure 3.3.1.
Clients connect to the server API using the Client (FUSE) module and user authentication data is used to achieve a secure connection. The Client (FUSE) module uses a Windows FUSE Module, as described in Section 2.4. The Client (FUSE) module creates and presents the virtual filesystem in an integrated way that Windows can use and interact with it.
CHAPTER 3. SYSTEM ARCHITECTURE
The Classification Service Module runs as a Windows service that enables classification functionality in Windows File Explorer. These functionalities allow users to set classifications and tags by rightclicking a file and calling functions from the Classification Module. The following sections explain the different modules in further detail.
Figure 3.3.1: Client Architecture. All client modules for a Windows client. The client uses a Windows FUSE module to create a virtual filesystem for Windows with data from the server. A classification module and service create a Windows integration that allows classifications and tags to be set on files in the virtual filesystem.
3.3.1 Client (FUSE)
The Client (FUSE) module handles connections to the server using the WebDAV protocol with an extension that allows for classification and tag metadata to be appended. This communication is made secure through authentication and secure communication protocols. The module is be able to handle all communication that is expected of a network storage system. The classification and tag data that is needed, is retrieved from the Classification Module if they are not already attached to the request when this module receives it.
An example of how the Client (FUSE) module handles file requests:
1. A file operation is requested and no classification is set.
2. The request is paused.
3. The Classification Module is called to set a classification.
4. The classification metadata is appended to the request.
5. The request is sent to the server API.
CHAPTER 3. SYSTEM ARCHITECTURE
3.3.2 Windows FUSE Module
The Windows FUSE Module is used to create a virtual filesystem in userspace. The module has hooks into the Windows OS allowing the regular Windows file explorer to present the virtual filesystem. By using this implementation, other programs can interact with the files in the virtual filesystem as if they were local files.
3.3.3 Classification Service
The Classification Service is an active Windows service that enables classification features on files that are in the virtual filesystem presented by the Windows FUSE Module. These features set icon overlays and add functions to the rightclick menu for the files as seen in the mockup Figure 3.3.2. The icon overlays on files making it visually easy to distinguish different classifications. The rightclick menu is extended with classification and tag functionality that correspond with functions in the Classification Module.
Figure 3.3.2: Mockup of client implementation where file classifications are displayed and an easy rightclick classification change feature is displayed.
CHAPTER 3. SYSTEM ARCHITECTURE
3.3.4 Classification Module
The Classification Module handles classification and tag functionality for all file operations that could change classifications or tags. This includes both requests from the operating system through the Client (FUSE) module and manual requests from the Classification Service.
Requests from the operating system are verified to confirm that classifications are set and that the current user has the privilege to do so. Valid requests continue to the server while invalid requests are blocked. For blocked requests, the user is prompted with the classification options that apply for the file and is forced to set a classification before the request is allowed to continue.
When users need to add or change classifications and tags, this module provides users with the available classification options on the server and excludes options that policies of selected tags require. For example: files with the Company Contracts tag can not be saved with a Public classification, requiring Confidential classification.
These policies are configured on the server and the client requests these settings on connecting. All changes made, are added to requests as classification and tag metadata and sent to the server API using the Client (FUSE) module.
3.4 Summary
In this chapter, the overall architecture of the Classification Storage system was outlined. The described Client–Server architecture aims to achieve the thesis and system goals. The server hosts a virtual filesystem based on a virtual storage that is a combination of storage locations that represent different classification levels. Clients connect to the server using an extended WebDAV protocol, allowing for classification and tag metadata to be communicated. The client makes use of FUSE to create a virtual filesystem in userspace allowing for a seamless windows integration. All the main modules in both the client and server are described in detail and design choices are explained. The implementation of this architecture is described and discussed in the next chapter.
Chapter 4
System Implementation
In this chapter, the Classification Storage system is described as it has been implemented for this thesis. The system is developed largely following the architecture described in Chapter 3. For the Authentication Module and the client GUI, modifications are made that proved to be better solutions or needed to be down scaled because of time restrains. The Authentication Module on the server is not implemented because this is to time consuming for this thesis. For the implementation of the client, the changing of file classifications is improved by utilizing a more user friendly GUI instead of the rightclick menu described in Section 3.3.3.
This chapter starts with describing the server implementation in Section 4.1. The server implementation is described through the three main components, Sabre/DAV, Virtual Filesystem and Classification Plugin. Following the server description the client implementation is described in Section 4.2. The client is described in three sections, CSFS, CSShellExtension and CSDialogBox. Lastly, the chapter is summarized in Section 4.3
4.1 Server
The implementation of the Classification Storage server runs in a Linux environment on a web server. The server is created as a Virtual Machine (VM) in VirtualBox [28].
Ubuntu 20.04 is chosen as server OS and for the web server Apache is decided on, as explained in Section 3.2. The following versions were used in the server Environment.
CHAPTER 4. SYSTEM IMPLEMENTATION
Server environment
Virtualization Software VirtualBox 6.1.16
Operating system
Linux 5.4.0-67-generic Ubuntu 20.04.1 LTS Web Server
Apache/2.4.41 (Ubuntu) PHP 7.4.3
Figure 4.1.1: Server Implementation. The figure illustrates implemented server modules and how they interact within the server. An Apache web server is the bases for the server software. On the web server the Sabre/DAV webDAV software is running with two plugins that together handle all logic and communication with the clients and the different storage locations.
The server is designed using four main modules, Sabre/DAV, Virtual Filesystem, Server API and the Authentication Module. Because of time constrains the Authentication Module was not implemented and is an item of future work for this thesis. The Server API module was originally intended to handle all the connections. This would have created a space where the classification and tag metadata could be extracted and used to manage the way files are stored. During implementation this is found to not be the best solution because the Sabre/DAV framework proved more robust and well suited. Instead this logic is implemented as the Classification Plugin that extends the Sabre/DAV framework, as seen in Figure 4.1.1.
CHAPTER 4. SYSTEM IMPLEMENTATION
The Sabre/DAV framework handles much of the server side functionality as it manages the communication with clients through the WebDAV protocol and it connects the Virtual Filesystem and the Classification Plugin. The implemented structure is presented in Figure 4.1.1. Sabre/DAV, Virtual filesystem and Classification Plugin are further described in the following sections.
4.1.1 Sabre/DAV
Sabre/DAV is a framework for a WebDAV server that runs in a PHP web server environment. Sabre/DAV has many different features and plugins that can be utilized.
One of the main features that makes Sabre/DAV a good fit for this project is a plugin that achieves file locking. File locking is a necessary feature when multiple clients want to access the same file. The plugin handles the conflicts that can arrive, preventing potential data loss. The framework also allows for middleware to be added, making it possible to intercept and manipulate server requests and responses.
The Sabre/DAV framework includes a fully functional WebDAV server following the IETF defined WebDAV protocol as described in Section 2.1. The server is originally initiated with a root directory that maps to a directory on the server as seen in Figure 4.1.2. That root directory is shared using the WebDAV server software, allowing any WebDAV client to connect and edit the files in the directory.
1 $rootDirectory = new DAV\FS\ Directory ('public ');
2 $server = new DAV\ Server ( $rootDirectory );
Figure 4.1.2: PHP code of the Sabre/DAV WebDAV server initiation with a single directory as root directory.
The Classification Storage server requires multiple file storage sources to be combined into one virtual filesystem. This can not be achieved with the single root directory approach shown in Figure 4.1.2. This is solved by creating custom Directory, File and Root classes that combine into a virtual filesystem, which is further explained in the Virtual Filesystem section.
1 $lockBackend = new DAV\ Locks \ Backend \File('data/locks ');
2 $lockPlugin = new DAV\ Locks \ Plugin ( $lockBackend );
3 $server -> addPlugin ( $lockPlugin );
4
5 $csClassificationPlugin = new CSClassificationPlugin ();
6 $server -> addPlugin ( $csClassificationPlugin );
Figure 4.1.3: PHP code of the lockPlugin and the csClassificationPlugin that are added to the Sabre/DAV WebDAV server.
CHAPTER 4. SYSTEM IMPLEMENTATION
Plugins are added to the server after the server is initiated. The important plugins are the lockPlugin and the csClassificationPlugin, as seen in Figure 4.1.3. The lockPlugin prevents file operation collisions between multiple clients on the WebDAV server. The csClassificationPlugin is a custom middleware to handle classification data and is further explained in the Classification Plugin section.
4.1.2 Virtual Filesystem
The virtual filesystem is created in three main classes. A directory class, file class and a root class. The Sabre/DAV chapter explained that the server is initialised with the a root directory. This root directory maps a location on the server to instances of the directory and file classes. These classes together are the filesystem that is shared to clients.
The root class is used to allow for multiple locations to be merged together into one virtual filesystem. The root paths of all the different desired classification levels, and an enumerate classification value, are defined as CSRoots as seen in Figure 4.1.4. These roots are used to always store data according to their classification and are used in CSDirectory. The CSDirectory is used to initialize the server with a virtual filesystem instead of a regular singular filesystem location.
1 $Public = new ClassificationStorage \ CSRoot ('public /A', 1000) ;
2 $Internal = new ClassificationStorage \ CSRoot ('public /B', 2000) ;
3 $Restricted = new ClassificationStorage \ CSRoot ('public /C', 3000) ;
4 $Confidential = new ClassificationStorage \ CSRoot ('public /D', 4000) ;
5 $Secret = new ClassificationStorage \ CSRoot ('public /E', 5000) ;
6
7 $csRoots = new ClassificationStorage \ CSRoots ([
8 $Public ,
9 $Internal ,
10 $Restricted ,
11 $Confidential ,
12 $Secret
13 ]);
14
15 $rootDirectory = new ClassificationStorage \ CSDirectory ('', $csRoots );
16
17 $server = new DAV\ Server ( $rootDirectory );
Figure 4.1.4: PHP code of the initialisation of CSRoots that contains the root directory paths and classification values for the different classification levels.
CSDirectory holds most of the important functions that a filesystem needs to function properly. This is where requests from an OS or in this case WebDAV client eventual come to manipulate files and data. The CSDirectory class features functions like getChildren, getChild, createFile, createDirectory, setName and delete.
All these functions are written with a strong connection to the CSRoots class as they need to perform the file operations on any storage location dependent on file classification.
CHAPTER 4. SYSTEM IMPLEMENTATION
Figure 4.1.5: The left figure shows the file locations divided over the different classifications represented by A, B, C, D and E. The Right figure show the virtual files as presented to the clients.
An example of the virtualisation is the getChildren function that not only returns all children from a single location, but appends the children from all different root locations into one list. All functions are taking the multiple root paths into consideration when executing, always following the set classifications creating a virtual filesystem as seen in Figure 4.1.5.
CSFile is used to handle all the file specific operations such as writing data, reading data and changing a filename. The CSFile instances are created in the createFile function in the CSDirectory class. These objects represent the actual files that are stored on any of the different storage locations. All files that are represented this way have a classification value on them that is based on their root path. New files that are created through the client will have classification data that is used to determine where a file should be created. The classification data is parsed from client requests in the Classification Plugin and passed to the CSDirectory and CSFile classes.
4.1.3 Classification Plugin
The Classification Plugin is a middleware that holds functions that execute on different types of request and responses. The main functionality of this middleware is to handle all classification and tag data to and from clients. Not all operations require classification or tag data to be send in the request to perform the operation. The middleware only activates on operations that require classifications.
CHAPTER 4. SYSTEM IMPLEMENTATION
The following operations require classification or tag data:
• CreateFile: creates a file and requires a classification to set the correct file path.
• PropFind: requests that expect information about a certain file or directory to be returned, including classification and tag metadata.
• Move: when moving a file to a new location, tags need to be copied with the original file.
• ChangeClassification: when a client changes classification for a file, the file needs to be moved to a different root path.
When a CreateFile request is received, the middleware will extract classification and tag data from the request header as seen in Figure 4.1.6. The data is passed to the CSDirectory where a CSFile is created. Along with the creation of the file a tags file is created that holds the tag data. Tags are stored as a bit field structure in a separate file next to the original file. These tag files have the same name as the original file, but with a .cstags appended to it.
1 $csclassification = $httpRequest -> getHeader (" csclassification ");
2
3 $cstags = $httpRequest -> getHeader (" cstags ");
Figure 4.1.6: PHP code where classification and tag metadata is extracted from the httpRequest headers.
PropFind requests are among the most common requests in this system and they are used to inform clients about properties of the requested file or directory. The middleware checks what file the request is for and determines its classification and tag values. These values are added to the response header and send to the client, as seen in Figure 4.1.7.
1 $propfind ->set('{DAV :} csclassification ', $csvalue );
Figure 4.1.7: PHP code where the header value for propfind is set.
The Move operation and ChangeClassification are closely connected as changing a classification for a file requires the file to be moved to the root path of the new classification. Because of this, a special header is sent when a classification is changed.
If the cschangeclassification header is set, the middleware moves the file to the new location corresponding to the new classification that is provided. After the file is moved the tags file is moved to the same location, whether the cschangeclassification header is set or not.
CHAPTER 4. SYSTEM IMPLEMENTATION
4.2 Client
The Classification Storage client is implemented in a Windows environment as explained in Section 3.1.3. The Windows environment where the client is installed and tested is running as a VM just as the server is. The client environment has the following specifications.
Client environment
Virtualization Software VirtualBox 6.1.16
Operating system
Windows 10 Enterprise Evaluation Version 20H2
OS build 19042.867
The client consists of three main parts: Classification Storage FileSystem (CSFS), CSShellExtension and CSDialogBox. Because this is a Windows client the choice was made to implement the client in the C Sharp programming language.
• CSFS is a filesystem that communicates all file operations with the server through an extended WebDAV protocol. CSFS is the implemented counterpart of the Client (FUSE) module and the Classification Module that is described in Sections 3.3.1 and 3.3.4.
• CSShellExtension is a collection of Windows Shell Extensions that handle overlay icons and adds classification options when rightclicking a file in CSFS.
CSShellExtension is the implemented counterpart of the Classification Service module as described in Section 3.3.3.
• The CSDialogBox is a popup window that lets users set tags and a classification through a Graphical User Interface (GUI). This is used by both CSFS and CSShellExtension to let users perform classifications when these are required by file operations.
CHAPTER 4. SYSTEM IMPLEMENTATION
4.2.1 CSFS
CSFS is the main program in the client. CSFS creates and mounts a virtual network storage that is mounted to a volume in Windows, as seen in Figure 4.2.1. the virtual network storage has all its file operations connected to the server through an extended WebDAV protocol implementation.
Figure 4.2.1: CSFS mounted as network drive on volume W: in Windows.
CSFS uses WinFSP to create a custom filesystem [42]. WinFSP functions as the Windows FUSE Module that is described in Section 3.3.2. WinFSP is used by CSFS to integrate the custom filesystem with Windows, allowing data to be manipulated through the standard Windows file APIs. WinFSP provides a framework that can create a virtual filesystem that is able to be mounted as a network storage. The framework also provides a base class called FileSystemBase. This base class provides hooks into Windows API and CSFS inherits this. By doing so the CSFS class is able to handle all filesystem operations that applications send through Windows. The following custom functions are defined in CSFS, together creating the virtual filesystem.
• CanDelete
• Cleanup
• Close
• Create
• Flush
• GetFileInfo
• GetVolumeInfo
• GetSecurityByName
• Open
• Overwrite
• Read
• ReadDirectoryEntry
• Rename
• SetBasicInfo
• SetFileSize
• Write
CHAPTER 4. SYSTEM IMPLEMENTATION
One of the unique features of CSFS is the requirement for all files to have a classification set at all times. This means that no file can be created in this system without the user being required to set a classification. This is handled in the Create function by pausing the current create process and launching CSDialogBox. User input determines the classification of the file and is returned to the paused process. After a classification is set the paused process continues creating the file and if no classification is set the process is aborted.
There are two main components that most of the functions are dependent on, CSFileNode and CSWebDAV. The CSFilenode is a file node component that can ether represent a file or a directory in the filesystem. The CSWebDAV is a custom WebDAV client that is used to connect to the server and communicate all the file operations and share data.
CSFileNode
The CSFileNode class is used to send data between different functions and is one of the core building blocks of the virtual filesystem. When Windows requests information about a certain file or directory, the CSFileNode is the object in the filesystem that contains this information. The class has information such as, nodeName, nodeUri, isCollection, fileInfo and CSClassification. This information is retrieved from the server when, for example a directory lists all the files it contains. The different file operations use this information to properly send requests to the server to execute operations.
CSWebDAV
To communicate with the server an extended WebDAV protocol is used and CSWebDAV is the class that implements this. The base WebDAV client that is used is called WebDav.Client and is a widely used WebDAV client implemented following the official WebDAV standard RFC4918 [16, 34]. The following functions in the WebDAV protocol are used in CSFS.
• Delete: Deletes a file or directory.
• GetRawFile: Retrieves file data.
• Mkcol: Creates a directory.
• Move: Moves a file or directory.
• Propfind: Retrieves file or directory properties.
• PutFile: Writes data to a file.
CSWebDav extends the base WebDAV client with features to allow classification and tag data to be communicated to the client. The headers for the different functions were extended to allow for classification and tag data to be send and parsed, as seen in Figure 4.2.2.
CHAPTER 4. SYSTEM IMPLEMENTATION
1 PutFileParameters putParam = new PutFileParameters
2 {
3 Headers = new List < KeyValuePair <string, string>>
4 {
5 new KeyValuePair <string, string>(
6 " csclassification ",
7 node. classification
8 ),
9 new KeyValuePair <string, string>(
10 " cstags ",
11 true. ToString ()
12 ),
13 }
14 };
Figure 4.2.2: C Sharp code of classification and tag data being added as headers for a PutFile request.
4.2.2 CSShellExtension
CSShellExtension is a Windows Shell Extension as described in Section 2.5. This shell extension is created with a shell extension library called SharpShell [8]. The shell extension handles icon overlay and a rightclick context menu. These features are only active on files that are stored on CSFS.
Icon Overlay
The icon overlay is implemented for every classification level that the system is designed for. The system was designed for five different levels, with every level having an overlay icon associated with it as seen in Figure 4.2.3. To implement and integrate these overlay icons with Windows, three functions need to be defined, CanShowOverlay, GetOverlayIcon and GetPriority. CanShowOverlay is responsible to determine if an overlay icon should be displayed or not. The extension communicates with CSFS to determine the classification level of the file being processed and returns true for the icon that matches that level. The GetOverlayIcon returns the determined icon from the extension resources that are loaded into the Windows register when the extensions is installed. Lastly GetPriority is required to settle any conflicts if multiple icons are returning true from CanShowOverlay. These five icons have been given priorities 11 for I, 12 for II, 13 for III, 14 for IV and 15 for V.
This way the higher classification is selected in case of a conflict.
Figure 4.2.3: I = Public. II = Internal. III = Restricted. IV = Confidential. V = Secret.
Overlay icons 15 as presented in CSFS.
CHAPTER 4. SYSTEM IMPLEMENTATION
Figure 4.2.4: Context Menu with Change Classification entry, as presented in CSFS.
Context Menu
The context menu adds one entry to the rightclick menu of files on CSFS. This entry is “Change Classification” and selecting this option will open the CSDialogBox for the file that is rightclicked on, as seen in Figure 4.2.4.
This is a slight change in implementation from the original design. The original design has two entries, one for classification and one for tags. The thought was to change classifications and tags through this menu only. This was changed during implementation to enhance usability and cooperation between tags and classifications, and is discussed in more detail in Section 4.2.3.
The Change Classification entry is connected to a function that performs four tasks.
Firstly, the function connects to the Classification Storage server using CSWebDAV as described in Section 4.2.1. Secondly, a CSDialogBox is executed as a new process and the current process is paused to wait for the return value of CSDialogBox, as seen in Figure 4.2.5. Thirdly, the return value of CSDialogBox is send to the server with a cschangeclassification request. The cschangeclassification request moves the file from its previous classifications storage location to the location that matches the new classification. Lastly the folder of the changed file is refreshed to display the new classification level.
CHAPTER 4. SYSTEM IMPLEMENTATION
1 string arguments = $"\"{ filePath }\" { classification }";
2
3 Process process = new Process ();
4
5 process . StartInfo . FileName = CSDIALOGBOXPATH ;
6 process . StartInfo . Arguments = arguments ;
7 process .Start ();
8
9 process . WaitForExit ();
10
11 exitcode = process . ExitCode ;
Figure 4.2.5: C Sharp code of Change Classification function to execute CSDialogBox as new process and wait for return value.
4.2.3 CSDialogBox
The CSDialogBox is a small application that is used as a popup dialog box where tags and a classification can be set by users. The CSDialogBox has a minimal GUI with only tree pieces of information, file name, tags and classification, as seen in Figure 4.2.6.
This design originally only intended to be used to set classifications and tags in CSFS when a new file is created. The original architecture for changing classifications and tags was to be implemented as an interactive context menu when rightclicking file in CSFS, as seen in Figure 3.3.2. The rightclick menu is changed to also implement the CSDialogBox to create unity in setting classifications and because we found the CSDialogBox to be more intuitive and easy to use.
A user is prompted with this application when a new file is created on CSFS or when a user wants to change a classification through the rightclick context menu. A filename and current classification (if available) are used as parameters when launching the application and these are displayed to the user.
Users have three paths through the application:
1. Selecting the desired classification directly and clicking Save. This returns the new classification value for the file.
2. Selecting tags that match the content of the file. This excludes certain classification levels based on the requirements that the selected tags are associate with. (An example can be seen in Figure 4.2.6, where the Public classification level is excluded because one of the tags selected requires Internal or higher storage.) The minimal requirements are determined using tags and the user can decide if the minimal classification is sufficient or if they want to select a higher classification. The classification and tags are returned when the user clicks Save.
3. The user can click Cancel, in which case the application returns 1.
CHAPTER 4. SYSTEM IMPLEMENTATION
Figure 4.2.6: CSDialogBox GUI. Multiple tags are selected and there requirements cause the Public classification level to be disabled. The Internal classification level is selected.
Both CSFS and the context menu handle the return values the same way. First, the value is compared against 1, if that is the case than the classification is not successfully and the current thread is aborted. In the case of CSFS, this mean that a file is not created. In the case of the context menu, the file keeps its previous classification and tag values and no changes are made. When the application returns a classification and tags, this metadata is sent to the server and used to store the file in the correct location and stores the selected tags alongside it.
The CSDialogBox is implemented dynamically and most aspects, like classifications and tags, can easily be changed through the config file that is loaded when the application is started. The config file holds the tags and requirements that each tag has, along with the number of classification levels and the names associated with them.
4.3 Summary
In this chapter the implementation of the Classification Storage system is described.
The implementation consists of a custom Client–Server configuration. The server implementation consists of a PHP webserver that runs Sabre/DAV with a virtual filesystem and a classification plugin. These components together share a virtual filesystem with clients through an extended WebDAV implementation. The client implementation consists of three parts, CSFS, CSShellExtension and CSDialogBox.
CSFS is a virtual filesystem that connects and communicates to the server and displays that virtual filesystem to the user as a network drive in Windows. The
CHAPTER 4. SYSTEM IMPLEMENTATION
CSShellExtension enables overlay icons and options to change classification for all files in the CSFS. All files that are saved to the CSFS are required to have a classification associated with them, and this is set through the GUI CSDialogBox. The next chapter will explain how the system is evaluated in this thesis.
