securing-filesystems ch-constitutes_filesystem.xml,NONE,1.1
Thomas R. Jones (trjones)
fedora-docs-commits at redhat.com
Thu Aug 18 03:25:17 UTC 2005
Author: trjones
Update of /cvs/docs/securing-filesystems
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26053/securing-filesystems
Added Files:
ch-constitutes_filesystem.xml
Log Message:
Initial Commit to the Fedora Docs Repository
--- NEW FILE ch-constitutes_filesystem.xml ---
<?xml version="1.0" encoding="US-ASCII"?>
<!-- ...................................................................... -->
<!-- SECURING FILESYSTEMS ................................................ -->
<!-- File: ch-constitutes_filesystem.xml .................................. -->
<!-- &Id$ -->
<chapter id="ch-fs">
<title>What Constitutes a Filesystem?</title>
<para>
That is a pretty broad question. Take the following definition into
consideration:
</para>
<para>
<blockquote>
<attribution>
<orgname class="nonprofit">
The Free On-line Dictionary of Computing
</orgname>
</attribution>
<literallayout>
<emphasis role="bold">file system</emphasis>
(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)
</literallayout>
</blockquote>
</para>
<para>
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; distribution.
It does, however, present a generalized description at a higher-level. This
high-level description is sufficient if you have a very limited exposure to the
components of a given filesystem. Then again that is not what we are here to do,
is it? With this in mind, we will be delving much deeper into the internals of the
entity collectively known as the "filesystem" to gain as much valuable knowledge
as possible to properly and most of all securely administer the filesystem(s)
available to the end-users of the &FC; distribution.
</para>
<para>
We are going to dive in head first into the convoluted world of objects, subjects,
and the permissions utilized by these entities during their communications 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 utilization 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.
</para>
<para>
Now that we are done kicking the tires — lets open the hood and see
what this baby has got, shall we?!
</para>
<section id="sn-fs-stds">
<title>Filesystem Standardization and Compliance</title>
<section id="sn-fs-stds-what">
<title>What is a Standard?</title>
<para>
With regards to a filesystem, <emphasis>a standard is a published document
that contains a set of guidelines as to what, when, and how a specific
entity should behave in a given situation.</emphasis> Essentially, the
documents that are referenced in the following sections are all guidelines
for the placement, structure, and behavior of the objects that compose a
filesystem.
</para>
<para>
As you will soon see, these are just guidelines. These guidelines are not
regulatory requirements. Deviation from a standard is generally
discouraged by the regulatory bodies. However, you will be presented with
some situations that warrant such a deviation from the standard. I don't
want to ruin it for you by saying anything more — so let's get
started.
</para>
</section>
<section id="sn-fs-stds-fedora">
<title>Standards Implemented in Fedora</title>
<para>
Fedora attempts to comply with as many of the industry standards as
possible. This position helps to ensure that the &FC; distribution
complies with the technical computing capabilities as the distribution
is further developed and is inundated with advances into more complex and
exciting technologies as they become available to the public.
</para>
<section id="sn-fs-stds-fhs">
<title>The Filesystem Hierarchy Standard</title>
<para>
This standard, commonly referred to as the <abbrev>FHS</abbrev>, has
been developed to provide a set of requirements and guidelines for
file and directory placement under any UNIX-like operating 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.
</para>
<para>
With reference to the topic at hand, it also provides the capability
to determine the appropriate access permissions needed for a given
object; due to the fact that this standardization provides another
source of information to ascertain the intended purposes of the object
located within this <abbrev>FHS</abbrev>-compliant system. This of
course is further dependent on the filesystem objects themselves.
Given the information provided by the <abbrev>FHS</abbrev> and that
derived from the procedures performed in various other sections of
this document, we can reliably begin to secure the filesystems of
fedora.
</para>
</section>
<section id="sn-fs-stds-ieee">
<title>IEEE &posix;.1</title>
<para>The following &posix; draft standards are recognized:</para>
<itemizedlist>
<listitem>
<para>
&posix; 1003.1e - Security <abbrev>API</abbrev>s
</para>
</listitem>
<listitem>
<para>
&posix; 1003.2c - Security Command and Utilities
</para>
</listitem>
</itemizedlist>
<para>
It is important to recognize that these are draft standards. Thus,
these drafts have not been officially approved for recommendation
as a standard by the standards bodies. However, given that there
is a void of comparative standards in the area of access control;
these specifications are currently the best-of-breed.
</para>
</section>
</section>
<section id="sn-fs-stds-compliance">
<title>Yes! Fedora is Non-Compliant</title>
<para>Give listing of non-compliance.</para>
</section>
</section>
<section id="sn-fs-objs">
<title>A Review of the Structure and Objects of a Filesystem</title>
<para>
In order to understand and follow the concepts and procedures provided in
this section there will need to be a degree of familiarity with the commands,
their available options and related terminology. This information is not
meant as a replacement for the commands documentation(e.g. Manual Pages) but
is intended as a tool to obtain a brief summary of the resources utilized in
this section. Please read and familiarize yourself with the following
resources before continuing.
</para>
<itemizedlist>
<title>Key Terminology and Concepts</title>
<listitem>
<para>
<emphasis>object</emphasis> - this entity is passive in nature. The
object is the entity that provides the information or data that is
being requested.
</para>
</listitem>
<listitem>
<para>
<emphasis>subject</emphasis> - this entity is active in nature. The
subject is the entity that is requesting the information or data that
is located in or about the object.
</para>
</listitem>
<listitem>
<para>
<emphasis>access</emphasis> - the process of information transfer
between an object and a subject.
</para>
</listitem>
<listitem>
<para>
<command>ls</command> - the application utilized to list the contents
of a directory object type. Common options are as follows: the
<option>-l</option> option formats the output into a long listing.
Provides details such as mode-based permissions, owning user and
owning group. The <option>-d</option> option presents the
information for the directory object type instead of its contents.
This option queries the parent object to the requested directory
object type to obtain the appropriate information.
</para>
</listitem>
<listitem>
<para>
<command>stat</command> - the application utilized to display the
status of an object or filesystem. Common options are as follows:
the <option>-f</option> option presents the status of a filesystem
rather than the status of the special object that is associated with
the requested entity.
</para>
</listitem>
</itemizedlist>
<important>
<para>
It is very important that the concept of an object and subject is easily
understood. Otherwise, procedures and/or techniques presented in later
chapters will be without meaning.
</para>
<para>
I would like to take the time to re-emphasize that a subject is the active
entity that is requesting the data or information. Conversely, the object
is the passive entity that houses the data or information that is being
requested!
</para>
</important>
<section id="sn-fs-objs-std">
<title>Standard Objects</title>
<para></para>
<section id="sn-fs-objs-std-reg">
<title>Regular File</title>
<para>
The <firstterm>regular file</firstterm> object is the most prevalent
object type found in a &FC; system. On my development system there are
some 263,000 plus regular file objects. This number will 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.
</para>
<para>
The regular file object type is composed of a great many file types.
Yes, that is very confusing; but read on. There are two very different
and completely separate references to a <quote><firstterm>file
type</firstterm></quote> in a Linux operating system such 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 needed facility
to convey the applicability of these concepts for all objects that
compose a filesystem.
</para>
<para>
First, is the file type that is utilized in
<firstterm>kernel-space</firstterm> — from this point forward
known as the <firstterm>object file type</firstterm> to reduce
confusion. This object file type is an all-encompassing data object
for all objects of the regular file type. Essentially the kernel
bundles all the regular file objects into a single category, the
object file type when processing these objects. It is irrelevant to
the kernel whether or not a file being accessed is a shell 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
<xref linkend="sn-fs-objs-spl">Special Objects</xref>.
</para>
<para>
Second, is the file type that is utilized in <firstterm>user-space
</firstterm>. This file type is the entity that you as an end-user
will interact with on a daily basis and is considered the standard
form of a regular file objects file type(unless you are a kernel or
device driver developer). In contrast with the kernel-space 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 files are
sometimes identified by the file extension portion of the filename
that is declared for this regular file object in its parent directory
object. And yet they sometimes are identified by the data or
information located in the file itself.
</para>
<para>
I can hear you already saying -- "What does that mean?". This concept
comes into play when determining the purpose of the regular file
object which will be presented and performed in <xref
linkend="sn-sec-eval-purpose">Determining a Filesystem Objects
Purpose</xref>. To make things a little easier to understand, lets
perform analysis of an object believed to be of the regular file
object type. As are most scenarios in a Linux environment, there are
many ways to go about obtaining the same information. We will obtain
this information by utilizing various methods and alterative
procedures so that we cannot only establish the necessary steps needed
but also to become increasingly familiar with the Linux environment
and its available security mechanisms.
</para>
<procedure id="sn-fs-objs-std-reg-1">
<para>
The first procedure we will perform in this section will be to
identify whether or not the object is in fact of the regular file
object type. This procedure is performed in the following
different steps:
</para>
<itemizedlist>
<listitem>
<para>
<xref linkend="sn-fs-objs-std-reg-1-ls"/> - Using the
<command>ls</command> command
</para>
</listitem>
<listitem>
<para>
<xref linkend="sn-fs-objs-std-reg-1-stat"/> - Using the
<command>stat</command> command
</para>
</listitem>
</itemizedlist>
<step id="sn-fs-objs-std-reg-1-ls">
<title>Using the <command>ls</command> command</title>
<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 directory(which
happens to be the directory
<filename>/home/thomas/Documents/example</filename>)
and presents the output in a long format.
</para>
<substeps>
<step id="sn-fs-objs-std-reg-1-ls-execution">
<title>Execution of the command</title>
<screen>
thomas at bodhittsatva:~/Documents/example> ls -l watch_osiris.sh
</screen>
</step>
<step id="sn-fs-objs-std-reg-1-ls-output">
<title>Output from the command</title>
<para>
As you can see from the output below, the long format
option provides us a great deal of information about
the regular file objects in this directory.
</para>
<screen>
-<co id="regular_file_type"/>rwxr--r-- 1 thomas<co id="regular_file_owner"/> thomas<co
id="regular_file_owning_group"/> 2506 2005-08-01 10:34 watch_osiris.sh
</screen>
</step>
<step id="sn-fs-objs-std-reg-1-ls-analysis">
<title>Analysis of the output</title>
<para>
The example output above provides other information
such as permissions. But, this will be reviewed in
another chapter so we will disregard this information
at this time and continue on with our topic.
</para>
<para>
Upon review of the example output presented in
<xref linkend="sn-fs-objs-std-reg-1-ls-output"/>, we
can determine the following specific information about
the suspected regular file object:
</para>
<calloutlist>
<title>
<filename>
/home/thomas/Documents/example/watch_osiris.sh
</filename>
</title>
<callout arearefs="regular_file_type">
This filesystem object is a regular file. The
representation of this information is in the form
of the <quote>-</quote> (dash) preceeding the
informational image location.
</callout>
<callout arearefs="regular_file_owner">
This regular file object is owned by the
<systemitem class="username">thomas</systemitem>
owner
</callout>
<callout arearefs="regular_file_owning_group">
This regular file object is owned by the
<systemitem class="groupname">thomas</systemitem>
owning group
</callout>
</calloutlist>
</step>
</substeps>
</step>
<step id="sn-fs-objs-std-reg-1-stat">
<title>Using the ??? command</title>
<para>
The same information can be gleaned from the utilization of
the <command>???</command> command.
</para>
</step>
</procedure>
</section>
<section id="sn-fs-objs-std-dir">
<title>Directory</title>
<para></para>
</section>
</section>
<section id="sn-fs-objs-spl">
<title>Special Objects</title>
<para></para>
<section id="sn-fs-objs-spl-char">
<title>Character Device</title>
<para>
As are most objects of a native filesystem of a linux operating
system, the special files known as character devices are also
categorized as <quote>file-like</quote> objects. Many characteristics
of a device file object are similar and sometimes identical to that
of the filesystem objects previously discussed. However, there are a
few key differences between other filesystem objects and character
device objects that will need to be examined. We will review the
affect these differences have on the specific filesystem object as
well as the security implications these differences have on the fedora
system as a whole.
</para>
<para>
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 directory entries that
are located in the directory object that is parent to the character
device. Generally, most character devices are located in the
<filename>/dev</filename> directory. This convention is standardized
by the following standards bodies:
</para>
<itemizedlist>
<listitem>
<para>Filesystem Hierarchy Standard</para>
<itemizedlist>
<listitem>
<para>
The most current standardization at time of this
writing is 2.3
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Linux Standard Base</para>
<itemizedlist>
<listitem>
<para>
The most current standardization at time of this
writing is 3.0
</para>
</listitem>
<listitem>
<para>
The related specification is located in Chapter 5,
Section 12.1
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Single Unix Specification</para>
<itemizedlist>
<listitem>
<para>
The most current standardization at time of this
writing is ?????
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
<para>
As has been previously declared, we will be utilizing the &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:
</para>
<para>
<ulink url="http://www.pathname.com/fhs/pub/fhs-2.3.html#DEVDEVICEFILES">
http://www.pathname.com/fhs/pub/fhs-2.3.html#DEVDEVICEFILES</ulink>
</para>
<para>Sometimes a character device is also called a </para>
</section>
<section id="sn-fs-objs-spl-blk">
<title>Block Device</title>
<para></para>
</section>
<section id="sn-fs-objs-spl-sym">
<title>Symbolic Link</title>
<para></para>
</section>
<section id="sn-fs-objs-spl-sock">
<title>Socket</title>
<para></para>
</section>
<section id="sn-fs-objs-spl-pipe">
<title>Pipe</title>
<para></para>
</section>
</section>
<section id="sn-fs-objs-adm">
<title>Administrative Objects</title>
<para></para>
<section id="sn-fs-objs-adm-inode">
<title>Inode: the Administration Data Object</title>
<para></para>
</section>
</section>
<section id="sn-fs-objs-path">
<title>Understanding a Pathname</title>
<para></para>
</section>
</section>
<section id="sn-fs-types">
<title>Types of Filesystems</title>
<para>
The following sections provide a listing of the filesystems that 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 licensing there are
a great multitude of filesystems that have been developed and/or 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 operating systems.
</para>
<section id="sn-fs-types-ext2">
<title>Ext2</title>
<para></para>
</section>
<section id="sn-fs-types-ext3">
<title>Ext3</title>
<para></para>
</section>
<section id="sn-fs-types-reiserfs">
<title>ReiserFS</title>
<para></para>
</section>
<section id="sn-fs-types-jfs">
<title>JFS</title>
<para></para>
</section>
<section id="sn-fs-types-xfs">
<title>XFS</title>
<para></para>
</section>
<section id="sn-fs-types-cfs">
<title>CFS</title>
<para></para>
</section>
<section id="sn-fs-types-tcfs">
<title>TCFS</title>
<para></para>
</section>
<section id="sn-fs-types-ramfs">
<title>RAMFS</title>
<para></para>
</section>
</section>
</chapter>
<!-- End of File: ch-constitutes_filesystem.xml ........................... -->
More information about the Fedora-docs-commits
mailing list