From fedora-docs-commits at redhat.com Wed Jun 10 15:28:38 2015 Content-Type: multipart/mixed; boundary="===============4535067741327074466==" MIME-Version: 1.0 From: fedora-docs-commits at redhat.com To: docs-commits at lists.fedoraproject.org Subject: securing-filesystems ch-constitutes_filesystem.xml,NONE,1.1 Date: Wed, 17 Aug 2005 23:25:17 -0400 Message-ID: <200508180325.j7I3PHkG026069@cvs-int.fedora.redhat.com> --===============4535067741327074466== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: trjones Update of /cvs/docs/securing-filesystems In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26053/securing-filesyst= ems Added Files: ch-constitutes_filesystem.xml = Log Message: Initial Commit to the Fedora Docs Repository --- NEW FILE ch-constitutes_filesystem.xml --- What Constitutes a Filesystem? That is a pretty broad question. Take the following definition into consideration:
The Free On-line Dictionary of Computing file system (FS, or "filesystem") 1. A system for organizing directories and files, generally in terms of how it is implemented in the disk operating system. E.g., "The Macintosh file system is just dandy as long as you don't have to interface it with any other file systems". 2. The collection of files and directories stored on a given drive (floppy drive, hard drive, disk partition, logical drive, RAM drive, etc.). E.g., "mount attaches a named file system to the file system hierarchy at the pathname location directory [...]" -- Unix manual page for "mount(8)". As an extension of this sense, "file system" is sometimes used to refer to the representation of the file system's organization (e.g. its file allocation table) as opposed the actual content of the files in the file system. Unix manual page: fs(5), mount(8). (1997-04-10)
Although the above statements properly define a filesystem, they do= not properly convey the complexities and nuances presented when interacting and = securing the various types of filesystems available to an end-user of the &FC; d= istribution. It does, however, present a generalized description at a higher-lev= el. This high-level description is sufficient if you have a very limited exp= osure to the components of a given filesystem. Then again that is not what we ar= e here to do, is it? With this in mind, we will be delving much deeper into the i= nternals of the entity collectively known as the "filesystem" to gain as much valua= ble knowledge as possible to properly and most of all securely administer the fil= esystem(s) available to the end-users of the &FC; distribution. We are going to dive in head first into the convoluted world of obj= ects, subjects, and the permissions utilized by these entities during their communi= cations with one another. The intention of this entire chapter is to build a in-= depth understanding of the internal structure of a filesystem and the uti= lization of the data contained therein. Within the next few sections we will review= these points and begin to build a solid comprehension of the object and subject = relationship that is the cornerstone of access control and subsequently a secure= filesystem. Now that we are done kicking the tires — lets open the hood a= nd see what this baby has got, shall we?!
Filesystem Standardization and Compliance
What is a Standard? With regards to a filesystem, a standard is a pub= lished document that contains a set of guidelines as to what, when, and how= a specific entity should behave in a given situation. Essen= tially, the documents that are referenced in the following sections are= all guidelines for the placement, structure, and behavior of the objects t= hat compose a filesystem. As you will soon see, these are just guidelines. These guid= elines are not regulatory requirements. Deviation from a standard is gener= ally discouraged by the regulatory bodies. However, you will be = presented with some situations that warrant such a deviation from the stan= dard. I don't want to ruin it for you by saying anything more — so = let's get started.
Standards Implemented in Fedora Fedora attempts to comply with as many of the industry stan= dards as possible. This position helps to ensure that the &FC; distr= ibution complies with the technical computing capabilities as the d= istribution is further developed and is inundated with advances into mo= re complex and exciting technologies as they become available to the publi= c.
The Filesystem Hierarchy Standard This standard, commonly referred to as the FHS<= /abbrev>, has been developed to provide a set of requirements and gui= delines for file and directory placement under any UNIX-like operat= ing system. It is intended to support interoperability of applications= , system administration tools, development tools, and scripts as= well as greater uniformity of documentation for these operating= systems. With reference to the topic at hand, it also provides t= he capability to determine the appropriate access permissions needed = for a given object; due to the fact that this standardization provi= des another source of information to ascertain the intended purpose= s of the object located within this FHS-compliant syst= em. This of course is further dependent on the filesystem objects t= hemselves. Given the information provided by the FHS and that derived from the procedures performed in various other = sections of this document, we can reliably begin to secure the file= systems of fedora.
IEEE &posix;.1 The following &posix; draft standards are recognized:= &posix; 1003.1e - Security APIs &posix; 1003.2c - Security Command and Utilities It is important to recognize that these are draft stand= ards. Thus, these drafts have not been officially approved for reco= mmendation as a standard by the standards bodies. However, given t= hat there is a void of comparative standards in the area of acces= s control; these specifications are currently the best-of-breed.
Yes! Fedora is Non-Compliant Give listing of non-compliance.
A Review of the Structure and Objects of a Filesystem In order to understand and follow the concepts and procedures p= rovided in this section there will need to be a degree of familiarity with= the commands, their available options and related terminology. This informati= on is not meant as a replacement for the commands documentation(e.g. Manu= al Pages) but is intended as a tool to obtain a brief summary of the resource= s utilized in this section. Please read and familiarize yourself with the fol= lowing resources before continuing. = Key Terminology and Concepts object - this entity is passive in= nature. The object is the entity that provides the information or d= ata that is being requested. = subject - this entity is active in= nature. The subject is the entity that is requesting the informatio= n or data that is located in or about the object. = access - the process of informatio= n transfer between an object and a subject. = = ls - the application utilized to lis= t the contents of a directory object type. Common options are as follo= ws: the option formats the output into a lo= ng listing. Provides details such as mode-based permissions, owning= user and owning group. The option presents t= he information for the directory object type instead of it= s contents. This option queries the parent object to the requested = directory object type to obtain the appropriate information. = stat - the application utilized to d= isplay the status of an object or filesystem. Common options are a= s follows: the option presents the status of a= filesystem rather than the status of the special object that is as= sociated with the requested entity. = It is very important that the concept of an object and subj= ect is easily understood. Otherwise, procedures and/or techniques present= ed in later chapters will be without meaning. = I would like to take the time to re-emphasize that a subjec= t is the active entity that is requesting the data or information. Converse= ly, the object is the passive entity that houses the data or information t= hat is being requested! =
Standard Objects
Regular File The regular file object is the m= ost prevalent object type found in a &FC; system. On my development s= ystem there are some 263,000 plus regular file objects. This number wil= l vary greatly between different systems due to installed applications= , and the utilization of the system itself. The amount of regular= file objects located on your system is not significant to the topic = at hand. However, it is relevant to know that most objects that = you will be securing will be of this type of filesystem object. = The regular file object type is composed of a great man= y file types. Yes, that is very confusing; but read on. There are two= very different and completely separate references to a file type in a Linux operating system su= ch as &FC;. These references are not as relevant to a regular file = object type as they are of the special object type but are indeed a ne= eded facility to convey the applicability of these concepts for all o= bjects that compose a filesystem. = First, is the file type that is utilized in kernel-space — from this p= oint forward known as the object file type to= reduce confusion. This object file type is an all-encompassing= data object for all objects of the regular file type. Essentially t= he kernel bundles all the regular file objects into a single cate= gory, the object file type when processing these objects. It is i= rrelevant to the kernel whether or not a file being accessed is a sh= ell script or an XML file. All the object file types are accessed the= same way within the kernel-space. This is in direct contrast to = how the kernel reacts when presented with the filesystem objects that = are considered to be of a special type. You may read this information = in Special Objects. = Second, is the file type that is utilized in user-space . This file type is the entity that you as = an end-user will interact with on a daily basis and is considered t= he standard form of a regular file objects file type(unless you are= a kernel or device driver developer). In contrast with the kernel-s= pace version, = this file type is not all-encompassing at all. In user-= space, the regular file objects are distinctly separated according= to the attributes of the object in question. These types of fi= les are sometimes identified by the file extension portion of t= he filename that is declared for this regular file object in its pa= rent directory object. And yet they sometimes are identified by the da= ta or information located in the file itself. = I can hear you already saying -- "What does that mean?"= . This concept comes into play when determining the purpose of the reg= ular file object which will be presented and performed in Determining a Filesyste= m Objects Purpose. To make things a little easier to under= stand, lets perform analysis of an object believed to be of the reg= ular file object type. As are most scenarios in a Linux environme= nt, there are many ways to go about obtaining the same information. W= e will obtain this information by utilizing various methods and alter= ative procedures so that we cannot only establish the necessa= ry steps needed but also to become increasingly familiar with the Linux= environment and its available security mechanisms. The first procedure we will perform in this section= will be to identify whether or not the object is in fact of th= e regular file object type. This procedure is performed in the fol= lowing different steps: = - Using the ls command - Using the stat command Using the <command>ls</command> command</tit= le> <para> The use of the <command>ls <option>-l</option><= /command> command sequence will perform a listing of the = object that we request which is located in the current directo= ry(which happens to be the directory <filename>/home/thomas/Documents/example</filen= ame>) and presents the output in a long format. </para> <substeps> <step id=3D"sn-fs-objs-std-reg-1-ls-execution"> <title>Execution of the command thomas(a)bodhittsatva:~/Documents/example> ls -l watch_osiris.sh Output from the command As you can see from the output below, t= he long format option provides us a great deal of info= rmation about the regular file objects in this direct= ory. -rwxr--r-- 1 thomas thomas 2506 2005-08-01 10:34 watch_osiris.sh Analysis of the output = The example output above provides other= information such as permissions. But, this will be = reviewed in another chapter so we will disregard th= is information at this time and continue on with our t= opic. = Upon review of the example output prese= nted in , we can determine the following specific in= formation about the suspected regular file object: <filename> /home/thomas/Documents/example/= watch_osiris.sh </filename> This filesystem object is a regular= file. The representation of this information = is in the form of the - (dash) prec= eeding the informational image location. = This regular file object is owned b= y the thom= as owner = This regular file object is owned b= y the tho= mas owning group Using the ??? command The same information can be gleaned from the ut= ilization of the ??? command.
Directory
Special Objects
Character Device As are most objects of a native filesystem of a linux o= perating system, the special files known as character devices ar= e also categorized as file-like objects. Many c= haracteristics of a device file object are similar and sometimes ident= ical to that of the filesystem objects previously discussed. However= , there are a few key differences between other filesystem objects an= d character device objects that will need to be examined. We will r= eview the affect these differences have on the specific filesyste= m object as well as the security implications these differences hav= e on the fedora system as a whole. Building upon the previous examples, a character device= is accessed by the end-user via the names given them in the filesystem= . These names can be determined by a low-level review of the director= y entries that are located in the directory object that is parent to t= he character device. Generally, most character devices are located i= n the /dev directory. This convention is= standardized by the following standards bodies: Filesystem Hierarchy Standard The most current standardization at tim= e of this writing is 2.3 Linux Standard Base The most current standardization at tim= e of this writing is 3.0 The related specification is located in= Chapter 5, Section 12.1 Single Unix Specification The most current standardization at tim= e of this writing is ????? As has been previously declared, we will be utilizing t= he &fhs; specification as the standardization of choice for this= document. You may navigate to the following link for more information= about character devices implemented under the &fhsu; standard: http://www.pathname.com/fhs/pub/fhs-2.3.html#DEVDEVICEF= ILES Sometimes a character device is also called a
Block Device
Symbolic Link
Socket
Pipe
Administrative Objects
Inode: the Administration Data Object
Understanding a Pathname
Types of Filesystems The following sections provide a listing of the filesystems tha= t are supported by the fedora kernel. This listing in no way is meant= to be an all inclusive summary. Due to the Linux kernels open source licensi= ng there are a great multitude of filesystems that have been developed and/o= r ported for use. This licensing unencumberance provides end-users, and all = users of Linux distributions; an easy avenue by which to remedy stability and = integrity issues of their filesystems introduced by various other operati= ng systems.
Ext2
Ext3
ReiserFS
JFS
XFS
CFS
TCFS
RAMFS
--===============4535067741327074466==--