Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 13 May 2001 01:07:50 +0400
Subject: "Owl", -- a security-enhanced GNU/*/Linux-based server platform


After months of development we're making public a prerelease of Owl,
our security-enhanced server platform with Linux and GNU software as
its core.

The homepage for Owl will be:

There's a mailing list where you can share your experience with Owl
and ask questions.  To subscribe, send an empty message to

Included below is a copy of Owl/doc/CONCEPTS (more documentation and
the download locations are available from the above URL).

	"Owl", -- a security-enhanced server platform.

"Owl" (or "Openwall GNU/*/Linux"; please, note that only the "O" is
capitalized in either case) is a security-enhanced operating system
with Linux and GNU software as its core, compatible with other major
distributions of GNU/*/Linux.  It is intended as a server platform.
And, of course, it's free.


While we value quality above feature set, Owl does indeed offer a
number of features besides just trying to be more secure.

Most obviously, Owl can be used as a base for installing whatever
software is generally available for GNU/*/Linux systems.  It offers
some compatibility (read below) for software packages found in or
developed for other major Linux distributions, such as Red Hat Linux.

Additionally, being a server platform, Owl will include a growing set
of integrated Internet services.  Only a few are available with the
prerelease, but this is one of the primary areas we will be working in.

Owl includes a complete build environment capable to re-build the
entire system from source with one simple command ("make buildworld").
(This is explained in more detail below.)

Owl supports multiple architectures (currently x86 and SPARC), as this
lets you use it in more cases and helps us catch certain classes of
software bugs earlier, thus improving the reliability of Owl packages.


Owl combines several approaches to reduce the number and/or impact of
flaws in its software components and impact of flaws in third-party
software that one might install on the system.

The primary approach used is proactive source code review for several
classes of software vulnerabilities.  However, because of the large
amount of code, there's a certain level of "importance" for a software
component or a part thereof to be audited.  Currently, only pieces of
code which are typically run with privileges greater than those of a
regular user and/or typically process data obtained over a network are
audited before the corresponding software component is included.  This
covers relevant code paths in many of the system libraries, all SUID/
SGID programs, all daemons and network services.  Other software may
be audited when it is already a part of Owl.  Potential problems found
during the audit are fixed or, in some pathological cases, may prevent
the software component from being included.  In general, code quality
and privilege management are always considered when there's a choice
between implementations of a feature.  As the project evolves, many of
the software components will be replaced with ones of our own.

When packaged for Owl, the software components are configured or, when
necessary, modified in order to provide safe defaults, apply the least
privilege principle, and introduce privilege separation.  The use of
safe defaults, where optional and potentially dangerous features need
to be turned on explicitly, lets us audit the pieces of code used in
in the default configuration in a more thorough way.  Extra systems
administration facilities ("owl-control") are provided for managing
system features such as the optional SUID/SGID binaries independently
from installing the corresponding packages.  Every Owl package will
have its audit status documented to allow for risk assessment.

While source code review is the preferred way to deal with software
vulnerabilities, it can't be applied in all cases.  Typically, when
insecure third-party software is installed on an otherwise secure
system, "the game" is lost.  The only thing an operating system can
guarantee is that potential unauthorized access would be limited to
those privileges granted to the software in question.  However, in the
recent years, a number of approaches were developed which reduce the
likelihood and/or may reduce the impact of successful real-world
attacks on insecure third-party software.  Owl will use some of those
"hardening" approaches in various parts of the system.

Owl uses "strong" cryptography within its core components, and already
includes some security policy enforcement (proactive password checking
with "pam_passwdqc", password and account expiration, network address-
based access control) and integrity checking ("mtree") capabilities.
It is one of our goals to provide a wide range of security tools with
Owl, available for use "out of the box".

	The build environment and package management.

Unlike most other "Linux distributions", Owl includes a complete build
environment capable to re-build the entire system from source with one
simple command ("make buildworld").  However, the implementation of
"make buildworld" on Owl is very different from that available with
*BSD.  It is in fact more similar to *BSD ports/packages, covering the
entire Owl userland (that is, everything but the Linux kernel).

The Owl userland source code consists of two directory trees, where
each Owl package may be split between the two trees.  One source tree
consists of original archives as distributed by the maintainers of the
corresponding software components.  The other tree, which we store in
a CVS repository, has the build specifications, patches, and other
Owl-specific additions to the packages.  Some packages were developed
as a part of Owl, and thus exist entirely in the CVS repository.

Based on the two source trees, binary packages are built.  They can be
installed (with "make installworld") to update the system itself or to
create a new Owl installation (the ROOT= setting), or they can be
transferred over a network and installed elsewhere.

We're using RPM for the binary packages, as that allows for reasonable
dependency handling when installing packages from or intended for Red
Hat Linux and several other distributions, on an Owl system.


Except for a few cases where this conflicts with our more important
goals, Owl tries to be binary- and package- compatible with several
other major distributions of GNU/*/Linux.  In particular, in most
cases it will be possible to install applications packaged for a
recent version of Red Hat Linux (currently, this applies to Red Hat
Linux 6.x) on Owl.

$Id: CONCEPTS,v 1.5 2001/05/11 18:47:26 solar Exp $

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.