-
OWL
Openwall GNU/*/Linux (or Owl for short) 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 is free.
-
-
There's a subdirectory for each Owl release or branch, with the following contents:
native.tar.gz CVS tree (our software, patches, build specs)
sources source tree (original tarballs to be patched)
kernel kernel sources and recommended patches
Owl.mtree mtree(8) specification of the above
i?86, sparc*, alpha* Owl binary packages
iso ISO-9660 images of Owl CDs
Some of the subdirectories may use symlinks to files common to several Owl branches. Thus, to download just one Owl branch you may need to tell your FTP client to dereference symlinks. With lftp (which is a part of Owl), use the "mirror -L" command.
The mtree(8) specifications for Owl releases are PGP signed. The corresponding PGP public key is available from:
http://www.openwall.com/signatures/
You will always need the CVS tree, -- even if you choose to install binary packages only. In order to (re-)build Owl from source, you'll need both the CVS and the source trees.
-
In addition to the availability of snapshots of the entire CVS tree on the FTP mirrors listed above, for experienced users there's public read-only access to a copy of our actual CVS repository provided via our anonymous CVS and CVSweb servers. To access the anonymous CVS server via the pserver protocol, set CVSROOT as follows:
CVSROOT=:pserver:anoncvs:[email protected] all.com:/cvs
alternatively, to access the anonymous CVS server over SSH, use:
CVS_RSH=ssh [email protected]:/cvs
The password is "anoncvs" and the module name is "Owl". You may use compression with either method of access to the anonymous CVS server, typically by specifying the -z3 option to CVS and/or "Compression yes" in the SSH client's configuration file.
Finally, the CVSweb interface is provided at:
http://cvsweb.openwall.com
-
"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.
Features.
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.
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, SPARC, and Alpha), 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.
Security.
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.
Compatibility.
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 Fedora Core or Red Hat Enterprise Linux on Owl.
-
The following is a list of architectures supported by Owl, their flavors and various architecture-specific details.
Architecture flavors.
On many architectures, Owl supports multiple flavors (or versions) of the architecture. For example, i386 and i686 are both versions of the x86 (IA32) architecture. It is possible (and in fact recommended, in most cases) to build and/or use binary packages intended for an older version of the architecture on your modern hardware.
Packages built for an architecture flavor closest to that implemented in your CPU may provide a small performance improvement (usually 1 to 5% overall on real-world tasks). However, there's a price: you won't be able to move such packages to an older machine and install there. Worse, you may not be able to build packages (or any binaries) for an older architecture flavor on a system where the development libraries were built for a newer one. The packages will appear to build and work, but may in fact require the newer architecture flavor due to code inherited from development libraries installed on the system.
There are two possible solutions to this last problem: you may choose to only use packages for the oldest architecture flavor you may ever need, or you may install development libraries built for the older flavor while using other packages (including dynamic libraries) built for your actual hardware. It is likely that you will find the first solution more practical, even though it doesn't provide the best possible performance.
Note that packages built for an older architecture flavor may be tuned for your newer CPU, to the extent possible within the feature set of the older flavor. This is how all Owl packages are built by default.
Building for a particular architecture flavor.
Architecture flavor may be specified via the ARCHITECTURE= line in buildworld.conf. This line is optional and commented out by default, in which case the oldest flavor of the build host's architecture is selected.
Cross-builds are not supported: it is not possible to build packages for an architecture different than that of the build host, nor for a flavor of the architecture newer than that implemented in the build host's CPU.
x86, also known as IA32.
Two architecture flavors are defined by default: i386 and i686. The i386 produces packages that will actually run on an i386 or on any newer CPU. Both the i386 and the i686 packages are tuned for an i686, with the only difference being that the i686 packages make use of the instructions only available with this newer architecture flavor.
It is recommended that you only use i386 packages, as the performance improvement with the i686 is minimal (less than 1% overall).
SPARC.
Two architecture flavors are defined: sparc and sparcv9. The sparc assumes at least a SPARC V8, and both produce packages tuned for an UltraSPARC. The sparcv9 packages will actually not work on anything below an Ultra.
The performance improvement with the sparcv9 is minimal (1 to 2%, except for certain functions in glibc and OpenSSL where SPARC V9 assembly versions are provided).
sparc64 is not supported at this stage (need to change glibc version first). It is possible to build Owl userland (32-bit) while running a sparc64 kernel, though.
Alpha.
Two architecture flavors are defined by default: alpha and alphaev56. The choice affects both the use of BWX extensions with alphaev56 and instruction scheduling. That is, packages built for plain alpha target are tuned for older EV4 processors (21064, 21066) and ones built for alphaev56 are tuned for EV56/PCA56 processors (21164A, 21164PC). On an EV5 (21164) processor you may use the suboptimal plain alpha packages. On an EV6+ (21264, 21264A), use the alphaev56 packages.
-
This is the guide on using the Owl build environment. It is assumed that you've read the CONCEPTS; if not, please do so before you proceed with this document.
/usr/src/world setup.
The build environment is pre-configured for the use of /usr/src/world (the HOME= setting in buildworld.conf and installworld.conf). It is recommended that you leave this default setting and either actually place the files in /usr/src/world or use a symlink if /usr/src is not on a suitable device (see below for the requirements).
When building natively (that is, on Owl), the directory is already there. Otherwise, you need to create the directory, add pseudo-user "build", preferably with UID 151 and GID 150 ("sources"), and make it the owner of the directory.
Place the CVS tree into /usr/src/world. The easiest way to do it is by extracting native.tar.gz available via the FTP mirrors. You will get the "native" directory, and a Makefile symlink.
For actually building from source, place the "sources" directory in /usr/src/world as well.
If you are not on an Owl system, yet, and want to install binary packages, create /usr/src/world/RPMS and place the packages for your architecture in there. Note that you need the CVS tree even for installing binary packages.
Requirements.
To (re-)build Owl from source, you'll need:
at least 1 GB free disk space under /usr/src/world for use during the builds;
at least 64 MB of physical memory (it is possible to build on less with sufficient swap space, but you'd better not);
at least 200 MB of virtual memory;
a few hours of CPU time, on a modern system.
And, of course, you should be running the build on Owl. Building on another GNU/*/Linux system is possible, but tricky and requires that you actually convert the system into Owl with multiple iterations of "make buildworld" and "make installworld".
Here are some build times (hours:minutes) for Owl-current, so that you know what to expect:
Dual Pentium 4 Xeon, HT (4-way MP), 2.8 GHz, 2 GB 0:50
Dual Pentium III, 600 MHz, 512 MB 3:35
UltraSparc IIi, 400 MHz, 256 MB 9:20
Alpha 21164PC (164SX-1MB), 533 MHz, 128 MB 13:30
(Yes, gcc is this hungry and slow on Alpha.)
The build times will increase as we add more packages and update to new versions of software already in Owl.
Native (re-)builds.
You need to have a configured Linux 2.4.x kernel in /usr/src/linux. As user "build", change directory to /usr/src/world and type:
make clean && make buildworld
With the default buildworld.conf, packages will be built for oldest flavor of the build host's architecture (see ARCHITECTURES) and the build will attempt to use all system processors.
buildworld.conf (as well as other *.conf's) may be edited by copying it from native/Owl/build into /usr/src/world. You need to remove the symlink first, if one has previously been created for you.
All packages are built with whatever versions of libraries and build tools are installed on the system. Multiple iterations of buildworld and installworld (two are sufficient most of the time) should be used when there have been significant updates to packages used during the builds.
Installing binary packages.
"make installworld" will install packages found in /usr/src/world/RPMS onto the current system, or in a new root directory of your choice (as specified by the ROOT= setting in installworld.conf). By default, the packages will be installed into /owl.
"make installworld" should be run as root.
(Re-)building individual packages.
Individual packages may be built or re-built with "make PACKAGE=name", where "name" is the name of the source package. For foreign packages (SRPMs) built with the Owl build environment you also need to include the version number part in "name".
-
The instructions below apply to Owl-current snapshots dated 2005/08/08 and newer (until revised). For older versions of Owl (such as the 1.1 release), please refer to Owl/doc/INSTALL as included in the "native" tree for your version (that's /usr/src/world/native/Owl/doc/INSTALL on the CDs).
Owl installation is currently more complicated than we'd like it to be. This is going to change with future releases.
Currently, there are two primary ways to install Owl, -- by booting off an Owl CD or by using another Linux installation you may already have.
Installing from a local CD-ROM drive.
If you don't already have an Owl CD, please either order one or see DOWNLOAD for locations where you may obtain the ISO-9660 CD images and burn one onto a CD-R.
The Owl CDs for x86 are bootable, so if your machine supports booting off a CD just do so. Otherwise take the boot floppy image from the CD under boot/floppy.image, write it onto a formatted 1.44 MB floppy (with dd(1) or an equivalent tool), and boot off the floppy. In either case, the boot loader will prompt you for your CD-ROM device which the kernel will use for the root filesystem. If you're using an IDE CD-ROM drive, select the proper IDE controller and whether the drive is set to master or slave. If you're using a SCSI CD-ROM drive, select "scsi".
Owl should boot into single user mode. At the root password prompt you can either just press Enter (as the CDs have a null password) or press Ctrl-D to let the system boot into multi-user right away (not recommended). If you chose to enter a single user shell, you have a chance to optionally configure the CD-booted system by simply typing:
setup
The configuration will be stored in RAM (parts of /etc and /var are on a ramdisk). You may then let the system boot into multi-user by exiting the shell. Of course, this step is optional and is only needed if it is more convenient to complete the installation while in multi-user mode (such as, operating from a remote workstation) or if you intend to actually use the CD-booted Owl without installing on a hard disk.
To actually install Owl, type:
settle
This will invoke the installer that will guide you through the installation process.
Please note that the installer currently does not install kernel sources or C headers (that you will need to build software from source on your newly installed system). You're supposed to copy them off the CD manually. (This is something we're planning to fix indeed.)
Using an existing Linux installation.
Note: these requirements and instructions are only relevant to you if you chose to not install from an Owl CD for whatever reason. Most people use a CD and don't need this.
A suitable Linux installation needs to offer some GNU tools and rpm2cpio. It does not have to use RPM as its package manager.
You need to prepare the usual /usr/src/world setup as explained in BUILD. Then proceed to install the new system:
Use fdisk(8) to partition your disks for Owl as desired. Use mkfs(8) and mkswap(8) to create filesystems and initialize swap space. Use mount(8) to mount the new root filesystem at /owl. Similarly, mount any additional filesystems at their appropriate locations under /owl. To actually install Owl, change directory to /usr/src/world and type:
make installworld && make setup
If there are any problems during the "installworld" stage (watch for the "Failed" lines), correct their cause and re-run the command.
Once the Owl userland is installed, you need to also install a kernel and configure a boot loader. Owl currently does not provide a pre-built kernel other than on the CDs, so you will need to either build the kernel from source (recommended) or copy the kernel image (/boot/bzImage and /boot/System.map) off an Owl CD.
Note that the kernel build and the boot loader setup need to be done chrooted to your newly installed userland:
chroot /owl
Currently, Owl supports Linux 2.4.x kernels. We recommend that you use the version provided with your copy of Owl.
You may choose to configure the boot loader available with Owl (LILO or SILO, depending on the architecture), or you may use a boot loader already installed on the system (if any).
Once the installation is complete, make sure to manually unmount the filesystems with umount(8) prior to rebooting the system.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
Senior Member
BizHat Geek
Reply With Quote
Bookmarks