Lightweight VM (FrebBSD Jails, Solaris zones)

"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum

The traditional UNIX security model is too simple for large enterprise environments. Before the invention of lightweight virtualization concept by BSD (BSD Jails) attempts to add more  fine-grained access control mostly failed. They failed mainly because they run against interest of users and dramatically increases both the cost of system management and implementation complexity.

In environments with a complex user applications, applications owners need pretty substantial set of privileges to be productive and this set of privileges typically approximates by granting them root access. But many roots on the server create the situation when right hand does not know what left is doing.  Known schemes of delegating of some management functions to application owners  under varying degrees of trust failed because they are prohibitively complex to create and maintain. That's why any solution that does not limit privileges meets such success. That is first of all true about sudo. It does improve some aspects of delegation (for example logging) and at the same time permit application owners to function preserving full productivity. Any security specialists know that multiple application owners factions that are typically present in a large corporation essentially drive measures to separate privileges. And that has consequences for data integrity, privacy protection and accountability for system configuration changes.  For example attempts to regularly change root password are doomed to be a failure as sudoers became the weakest link and other thing equal they try to preserve their set of passwords independently of efforts of UNIX system administrators.  Usually they succeed.

The first production lightweight VM was the FreeBSD "Jail" facility that was first introduced in FreeBSD in 1989. It provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX "root'' model. It also permit creation of  "virtual system images" - multiple instances of a running OS implemented as flexibly configured sandboxes.

In Jail, users with privilege find that the scope of their requests is limited to the jail, allowing system administrators to delegate management capabilities for each virtual machine environment. Creating virtual machines in this manner has many potential uses; the most popular thus far has been for providing virtual machine services in Internet Service Provider environments.

The current hosting industry is mostly based on regular user accounts accounts in which one account is capable of bringing down the whole server (for example, due to a run-away script) or using up most of the resources, which degrades the server's performance. If all of these virtual accounts can be sand-boxed from one another, then the host will be able to increase its service quality guarantee by offering each customer the guaranteed system resources - CPU, RAM, disk [space] - in accordance to the customer's needs.

FreeBSD is one of the most widely deployed operating systems used to serve content on the web. And Jails are one of the reason that FreeBSD managed to hold part of ISP space. The reasons for this are many, as FreeBSD promotes a tight security model, provides a full fledged UNIX architecture, and several built in features that make the operating system a superior choice for administrators concerned with security (isn't that all of us).

Lightweight VMs are now widely used for securing vital enterprise services that may be compromised by attackers such as BIND, Sendmail or other mail transport agents, and the Apache webserver. It structure the server into separate waterproof zones like ship and flooding og one zone does not threatens sinking the ship.

At the same time they preserve the autonomy of application owners as they still are entitled to access to a fully functioning root account, with all of the benefits and security concessions, incidental or intended. This provides the ability to delegate responsibility for the application security to application owners, so that application owner can scan start and stop processes, manage additional users and application accounts, install software, alter configuration files, and bind to ports less than 1024.

NEWS CONTENTS

• 20050304 : FreeBSD Process Management by George Neville-Neil, Marshall Kirk McKusick. Sample Chapter is provided courtesy of Addison Wesley Professional. ( FreeBSD Process Management, Mar 4, 2005 )
• 20050304 : Why share systems? ( )
• 20050304 : How to share systems ( )

Old News :-)

[Mar 4, 2005] FreeBSD Process Management By George Neville-Neil, Marshall Kirk McKusick. Sample Chapter is provided courtesy of Addison Wesley Professional.

The Jail Facility in FreeBSD 5.2 by Kirk McKusick (PDF)

Daemon News Inside Jail by Evan Sarmiento < [email protected] >

On most UNIX systems, root has omnipotent power. This promotes insecurity. If an attacker were to gain root on a system, he would have every function at his fingertips. In FreeBSD there are sysctls which dilute the power of root, in order to minimize the damage caused by an attacker. Specifically, one of these functions is called secure levels. Similarly, another function which is present from FreeBSD 4.0 and onward, is a utility called jail. Jail chroots an environment and sets certain restrictions on processes which are forked from within. For example, a jailed process cannot affect processes outside of the jail, utilize certain system calls, or inflict any damage on the main computer. Jail is becoming the new security model. People are running potentially vulnerable servers such as Apache, BIND, and sendmail within jails, so that if an attacker gains root within the Jail, it is only an annoyance, and not a devastation. This article focuses on the internals (source code) of Jail and Jail NG. It will also suggest improvements upon the jail code base which are already being worked on. If you are looking for a how-to on setting up a Jail, I suggest you look at my other article in Sys Admin Magazine, May 2001, entitled "Securing FreeBSD using Jail."

Queue - Building Systems to be Shared Securely - Running multiple virtual servers on one machine makes sense, but what happens when not everyone plays nice ACM Queue vol. 2, no. 5 - July/August 2004
by Poul-Henning Kamp, FreeBSD Developer, and Robert Watson, McAfee Research

The history of computing has been characterized by continuous transformation resulting from the dramatic increases in performance and drops in price described by Moore's law. Computing "power" has migrated from centralized mainframes/servers to distributed systems and the commodity desktop. Despite these changes, system sharing remains an important tool for computing. From the multitasking, file-sharing, and virtual machines of the desktop environment to the large-scale sharing of server-class ISP hardware in collocation centers, safely sharing hardware between mutually untrusting parties requires addressing critical concerns of accidental and malicious damage.

There has been a strong continuing interest in access control and separation technologies to support safe yet efficient sharing of computing systems. Although the degree of sharing taking place has increased because of similarly dramatic changes in networking, there has not been a marked change in the nature of security concerns. Costs of adapting software, identifying policy goals, and minimizing administrative complexity remain a balancing act. The fundamental security primitives for separation have not changed, but our experience in attempting to apply them is substantially greater.

In this discussion, we will review existing systems that provide strong separation via access control, virtualization, namespace management, and partitioning. We will then explore the FreeBSD Jail system, implemented by us, which adopts a hybrid approach to applying security primitives. We will pay particular attention to the implementation and administrative costs of modifying an existing system. We will also make recommendations for the design of new systems to facilitate the future introduction of security and separation features. These recommendations will reach the somewhat unsurprising conclusion that the path to security turns out to also be the path of improved and intentional software design and abstraction.

Why share systems?

The sharing of systems refers to the use of a system to serve simultaneous functions with differing security properties. Sharing systems offers the following benefits:

• In environments with inadequate computing resources, especially early computing environments and modern clusters, sharing allows for a more efficient use of valuable hardware resources, as well as for a joint investment in hardware resources.

• The development of ubiquitous local-area and wide-area networking has facilitated large-scale inter-system communication, permitting computers to become meeting points between individuals and organizations.

Although the terms of sharing have changed, the requirements remain largely the same: tasks and data representing the interests of multiple users coexisting on the same hardware platform.

The means to share common hardware resources has been a fertile area for research and development for decades. From the days of early time sharing, operating systems have been used as platforms for sharing by scheduling jobs, providing resource mediation and virtualization, and later providing access control. As data communication spread, the desire to connect and share data became a strong driver for sharing systems, placing focus on safe sharing.

Shared systems introduce inefficiencies such as slower performance; they also create serious security concerns. Security cannot simply be a question of retaining control of the system in a technical sense, but must also address moral and legal requirements for separation and privacy.

How to share systems

In this section we will discuss a number of existing systems generally representative of broad classes of similar systems allowing for resource sharing, as well as techniques that accomplish separation. We will first discuss a classic control-free environment and then consider the Unix process model, Unix discretionary access control, full virtual machine models, virtual machine-like execution environments, and classic trusted operating systems.

Strawman

The earliest types of system sharing consisted of primitive multiprogramming kernels that time-sliced among a number of processes or programs.¹ In these "strawman" systems, no separation techniques are applied and the hardware may not even offer facilities to provide qualified separation. All users/programs of the system have access to all resources on the system (memory, files, etc.). Accidental or intentional malicious behavior cannot be prevented or reliably recorded. It can be argued that both the administrative and user overhead from this separation model are almost nonexistent, since little can be done. But this is like saying that castor oil works against the common cold: you dare not cough.

Today these systems survive mainly in the embedded market where response-time requirements, resource constraints, and tightly controlled software integration make this approach a viable if painful methodology.

Unix Processes

Unix processes provide a basic virtual machine primitive, running each instance of an application in its own sandbox. Although not a complete emulation of the actual hardware environment, the process provides basic isolation and consistent interfaces. Each application instance operates with its own address space, copy of registers, and independent references to common system resources. The kernel provides abstracted access, virtualization, and synchronization primitives for system resources, permitting controlled and intentional communication.

The Unix process model strongly resembles those found on many past and current systems, including Windows NT, BSD (Berkeley Software Distribution) and Linux, and Mac OS X. Through the Posix standards, it has become the yardstick for application separation.

Unix Multi-User Security

In addition to process protections, Unix systems offer multi-user protection through a simple model of:

• Authenticated users

• Administrator-managed group system

• Simple discretionary access control lists for files/IPC objects

• Simple privilege model permitting the administrator to override protections and perform system management.

Properly configured, users, groups, and permissions may be used to provide integrity, confidentiality, and, to a lesser extent, availability protections among mutually untrusting users. The model scales poorly, however, requiring administrators to maintain the groups and requiring users to monitor and configure protections on all objects they own. The model lends itself well to discretionary protection in which users control access to objects they own, but poorly to mandatory protection, where the administrator requires controls that cannot be bypassed.

As with the Unix process model, many other systems have similar designs with similar benefits and pitfalls.

[May 20, 2004] Secure programmer Minimizing privileges Taking the fangs out of bugs David A. Wheeler ([email protected]) Research Staff Member, Institute for Defense Analyses

Secure programs must minimize privileges so that any bugs are less likely to be become security vulnerabilities. This article discusses how to minimize privileges by minimizing the privileged modules, the privileges granted, and the time the privileges are active. The article discusses not only some of the traditional UNIX-like mechanisms for privileges, but some of the newer mechanisms like the FreeBSD jail(), the Linux Security Modules (LSM) framework, and Security-Enhanced Linux (SELinux).

On March 3rd, 2003, Internet Security Systems warned of a serious vulnerability in Sendmail. All electronic mail is transferred using a mail transfer agent (MTA), and Sendmail is the most popular MTA, so this warning affected many organizations worldwide. The problem was that an e-mail message with a carefully-crafted "from," "to," or "cc" field could give the sender complete (root) control over any machine running Sendmail as it's commonly configured. Even worse, typical firewalls would not protect interior machines from this attack.

The immediate cause of the vulnerability was that one of Sendmail's security checks was flawed, permitting a buffer overflow. But a significant contributing factor is that Sendmail is often installed as a monolithic "setuid root" program, with complete control over the system it runs on. Thus, any flaw in Sendmail can give an attacker immediate control over the entire system.

Is this design necessary? No; a popular competing MTA is Wietse Venema's Postfix. Postfix, like Sendmail, does a number of security checks, but Postfix is also designed as a set of modules that minimize privilege. As a result, Postfix is generally accepted as a more secure program than Sendmail. This article discusses how to minimize privileges, so you can apply the same ideas to your programs.

Basics of minimizing privileges

Real-world programs have bugs in them. It's not what we want, but it's certainly what we get. Complicated requirements, schedule pressure, and changing environments all conspire to make useful bugless programs unlikely. Even programs formally proved correct using sophisticated mathematical techniques can have bugs. Why? One reason is that proofs must make many assumptions, and usually some of those assumptions aren't completely true. Most programs aren't examined that rigorously anyway, for a variety of reasons. And even if there are no bugs today (unlikely), a maintenance change or a change in the environment may introduce a bug later on. So, to handle the real world, we have to somehow develop secure programs in spite of the bugs in our programs.

One of the most important ways to secure programs, in spite of these bugs, is to minimize privileges. A privilege is simply permission to do something that not everyone is allowed to do. On a UNIX-like system, having the privileges of the "root" user, of another user, or being a member of a group are some of the most common kinds of privileges. Some systems let you give privileges to read or write a specific file. But no matter what, to minimize privileges:

• Give a privilege to only the parts of the program needing it
• Grant only the specific privileges that part absolutely requires
• Limit the time those privileges are active or can be activated to the absolute minimum

These are really goals, not hard absolutes. Your infrastructure (such as your operating system or virtual machine) may not make this easy to do precisely, or the effort to do it precisely may be so complicated that you'll introduce more bugs trying to do it precisely. But the closer you get to these goals, the less likely it will be that bugs will cause a security problem. Even if a bug causes a security problem, the problems it causes are likely to be less severe. And if you can ensure that only a tiny part of the program has special privileges, you can spend a lot of extra time making sure that one part resists attacks. This idea isn't new; the excellent 1975 paper by Saltzer and Schroeder discussing security principles specifically identifies minimizing privileges as a principle (see Resources). Some ideas, such as minimizing privileges, are timeless.

The next three sections discuss these goals in turn, including how to implement them on UNIX-like systems. After that we'll discuss some of the special mechanisms available in FreeBSD and Linux, including a discussion about NSA's Security-Enhanced Linux (SELinux).

Minimize privileged modules

As noted earlier, only the parts of the program that need a privilege should have the privilege. This means that when you're designing your program, try to break the program into separate parts so that only small and independent parts require special privileges.

If different parts must run concurrently, use processes (not threads) on UNIX-like systems. Threads share their security privileges, and a malfunctioning thread can interfere with all the other threads in a process. Write the privileged parts as though the rest of the program was attacking it: it might, someday! Make sure that the privileged part only does as little as possible; limited functionality means there's less to exploit.

One common approach is to create a command-line tool with special privileges (such as being setuid or setgid) that has an extremely limited function. The UNIX passwd command is an example; it's a command-line tool with special privileges to change the password (setuid root), but the only thing it can do is change passwords. Various GUI tools can then ask passwd to do the actual changing. Where possible, try to avoid creating setuid or setgid programs at all, because it's very difficult to make sure that you're really protecting all inputs. Nevertheless, sometimes you need to create setuid/setgid programs, so when it's necessary, make the program as small and as limited as possible.

There are many other approaches. For example, you could have a small "server" process that has special privileges; that server allows only certain requests, and only after verifying that the requester is allowed to make the request. Another common approach is to start a program with privileges, which then forks a second process that gives up all privileges and then does most of the work.

Be careful how these modules communicate with each other. On many UNIX-like systems, the command-line values and environment variable values can be viewed by other users, so they aren't a good way to privately send data between processes. Pipes work well, but be careful to avoid deadlock (a simple request/response protocol, with flushing on both sides, works well).

Minimize privileges granted

Ensure that you only grant the privileges a program actually needs -- and no more. The primary way that UNIX processes get privileges are the user and groups they can run as. Normally, processes run as the user and groups of their user, but a "setuid" or "setgid" program picks up the privileges of the user or group that owns the program.

Sadly, there are still developers on UNIX-like systems that reflexively give programs "setuid root" privileges. These developers think that they've made things "easy" for themselves, because now they don't have to think hard about exactly what privileges their programs need. The problem is that, since these programs can do literally anything on most UNIX-like systems, any bugs can quickly become a security disaster.

Don't give all possible privileges just because you need one simple task done. Instead, give programs only the privileges they need. If you can, run them as setgid not setuid -- setgid gives fewer privileges. Create special users and groups (don't use root), and use those for what you need. Make sure your executables are owned by root and only writeable by root, so others can't change them. Set very restrictive file permissions -- don't let anyone read or write files unless absolutely necessary, and use those special users and groups. An example of all this might be the standard conventions for game "top ten" scores. Many programs are "setgid games" so that only the game programs can modify the "top ten" scores, and the files storing the scores are owned by the group games (and only writeable by that group). Even if an attacker broke into a game program, all he could do would be to change the score files. Game developers still need to write their programs to protect against malicious score files, however.

One useful tool -- that unfortunately is a little hard to use -- is the chroot() system call. This system call changes what the process views when it views the "root" of the filesystem. If you plan to use this -- and it can be useful -- be prepared to take time to use it well. The "new root" has to be carefully prepared, which is complicated because correct application depends on the specifics of the platform and of the application. You must be root to make the chroot() call, and you should quickly change to non-root (a root user can escape a chroot environment, so if it's to be effective, you need to drop that privilege). And chroot doesn't change the network access. This can be a useful system call, so it's sometimes necessary to consider it, but be prepared for effort.

One often-forgotten tool is to limit resources, both for storage and for processes. This can be especially useful for limiting denial-of-service attacks:

• For storage, you can set quotas (limits) for the amount of storage or the number of files, per user and per group, for every mounted filesystem. On GNU/Linux systems see quota(1), quotactl(2), and quotaon(8) for more about this, but although they're not quite everywhere, quota systems are included in most UNIX-like systems. On GNU/Linux and many other systems, you can set "hard" limits (never to exceed) and "soft" limits (which can be temporarily exceeded).

• For processes, you can set a number of limits such as the number of open files, number of processes, and so on. Such capabilities are actually part of standards (such as the Single UNIX Specification), so they've nearly ubiquitous on UNIX-like systems; for more information, see getrlimit(2), setrlimit(2), and getrusage(2), sysconf(3), and ulimit(1). Processes can never exceed the "current limit," but they can raise the current limits all the way up to the "upper limit." Unfortunately, there's a weird terminology problem here that can trip you up. The "current limit" is also called the "soft" limit, and the upper limit is also called the "hard" limit. Thus, you have the bizarre situation that processes can never exceed the soft (current) limit of the process limits -- while for quotas you can exceed the soft limits. I suggest using the terms "current limit" and "upper limit" for process limits (never using the terms "soft" and "hard") so there's no confusion.

Minimize privileges' time

Give privileges only when they're needed -- and not a moment longer.

Where possible, use whatever privileges you need immediately and then permanently give them up. Once they're permanently given up, an attack later on can't try to exploit those privileges in novel ways. For example, a program that needs a single root privilege may get started as root (say, by being setuid root) and then switch to running as a less-privileged user. This is the approach taken by many Internet servers (including the Apache Web server). UNIX-like systems don't let just any program open up the TCP/IP ports 0 through 1023; you have to have root privileges. But most servers only need to open the port when they first start up, and after that they don't need the privilege any more. One approach is to run as root, open the privileged port as soon as possible, and then permanently drop root privileges (including any privileged groups the process belongs to). Try to drop all other derived privileges too; for example, close files requiring special privileges to open as soon as you can.

If you can't permanently give up the privilege, then you can at least temporarily drop the privilege as often as possible. This isn't as good as permanently dropping the privilege, since if an attacker can take control of your program, the attacker can re-enable the privilege and exploit it. Still, it's worth doing. Many attacks only work if they trick the privileged program into doing something unintended while its privileges are enabled (for example, by creating weird symbolic links and hard links). If the program doesn't normally have its privileges enabled, it's harder for an attacker to exploit the program.

Newer mechanisms
The principles we've discussed up to this point are actually true for just about any operating system, and the general mechanisms have been very similar between just about all UNIX-like systems since the 1970s. That doesn't mean they're useless; simplicity and the test of time have their own advantages. But some newer UNIX-like systems have added mechanisms to support least privilege that are worth knowing about. While it's easy to find out about the time-tested mechanisms, information about the newer mechanisms isn't as widely known. So, here I'll discuss a few selected worthies: the FreeBSD jail(), the Linux Security Modules (LSM) framework, and Security-Enhanced Linux (SELinux).

FreeBSD jail()

The system call chroot() has a number of problems, as noted above. For example, it's hard to use correctly, root users can still escape from it, and it doesn't control network access at all. The FreeBSD developers decided to add a new system call to counteract these problems, named jail(). This call is similar to chroot(), but strives to be both easier to use and more effective. Inside a jail, all requests (even root's) are limited to the jail, processes can only communicate with other processes in that jail, and the system blocks the typical ways root users try to escape from the jail. A jail is assigned a specific IP address, and can't use any others as its own address.

The jail() call is unique to FreeBSD, which currently limits its utility. But, there's a lot of cross-pollination between the various OSS/FS kernels. For example, a version of this jail has been developed for Linux using the Linux Security Framework. And FreeBSD 5 has added a flexible MAC framework (from the TrustedBSD project), including a module with functionality essentially like SELinux's. So don't be surprised to see more of this in the future.

Linux Security Modules (LSM)

At the 2001 Linux Kernel Summit, Linus Torvalds had a problem. Several different security projects, including the Security-Enhanced Linux (SELinux) project, had asked him to add their security approach to the Linux kernel. Problem was, these different approaches were often incompatible. Torvalds didn't have an easy way to determine which was best, so instead he asked the projects to work together to create some sort of general security framework for Linux. That way, administrators could install whichever security approach they wanted on their particular system. After some discussion with Torvalds, Crispin Cowan formed a group to create a general security framework. This framework was named the Linux Security Modules (LSM) framework, and is now part of the standard Linux kernel (as of kernel version 2.6).

Conceptually, the LSM framework is very simple. The Linux kernel still does its normal security checks; for example, if you want to write to a file, you still need write permission to it. However, any time that the Linux kernel needs to decide if access should be granted, it also checks -- asks a security module via a "hook" -- to determine whether or not the action is okay. This way, an administrator can simply pick the security module he wants to use and insert it like any other Linux kernel module. From then on, that security module decides what's allowed.

The LSM framework was designed to be so flexible that it can implement many different kinds of security policies. In fact, several different projects worked together to make sure that the LSM framework is sufficient for real work. For example, the LSM framework includes several calls when internal objects are created and deleted -- not because those operations might get stopped, but so that the security module can keep track of critical data. Several different analysis tools have been used to make sure that the LSM framework didn't miss any important hooks for its purposes. This project turned out to be harder than many imagined, and its success was hard-won.

The LSM made a fundamental design decision that's worth understanding. Fundamentally, the LSM framework was intentionally designed so that almost all of its hooks would be restrictive, not authoritative. An authoritative hook makes the absolute final decision: if the hook says a request should be granted, then it's granted no matter what. In contrast, a restrictive hook can only add additional restrictions; it can't grant new permissions. In theory, if all LSM hooks were authoritative, the LSM framework would be more flexible. One hook, named capable(), is authoritative -- but only because it it has to be to support normal POSIX capabilities. But making all the hooks authoritative would have involved many radical changes to the Linux kernel, and there was doubt that such changes would be accepted.

There were also many concerns that even the smallest bugs would be disastrous if most hooks were authoritative; while making the hooks restrictive meant that users would be unsurprised (no matter what, the original UNIX permissions would still normally work). So the LSM framework developers intentionally chose the restrictive approach, and most of its developers decided that they could work within the framework.

It's important to understand some of the LSM framework's other limitations, too. The LSM framework is designed to support only access control, not other security issues such as auditing. By themselves LSM modules can't log all requests or their results, because they won't see them all. Why? One reason is because the kernel might reject a request without even calling an LSM module; a problem if you wanted to audit the rejection. Also, due to concerns about performance, some proposed LSM hooks and data fields for networks were rejected for the mainline kernel. It's possible to control some network accesses, but it's not enough to support "labelled" network flows (where different packets have different security labels handled by the operating system). These are unfortunate limitations, and not fundamental to the general idea; hopefully the LSM framework will be extended someday to eliminate these limitations.

Still, even with these limitations, the LSM framework can be very useful for adding limits to privileges. Torvalds' goals were essentially met by the LSM framework: "I'm not interested in the fight between different security people. I want the indirection that gets me out of that picture, and then the market can fight out which policy and implementation actually ends up getting used."

So, if you want to limit the privileges you give your programs on Linux, you could create your very own Linux security module. If you want to impose truly exotic limitations, that may be necessary -- and the nice thing is that it's possible. However, this isn't trivial; no matter what, you're still writing kernel code. If possible, you're better off using one of the existing Linux security modules than trying to write your own. There are several LSM modules available, but one of the most mature of the Linux security modules is the Security-Enhanced Linux (SELinux) module, so let's look at that.

History of Security-Enhanced Linux (SELinux)

A little history will help you understand Security-Enhanced Linux (SELinux) -- and the history is interesting in its own right. The U.S. National Security Agency (NSA) has long been concerned about the limited security capabilities in most operating systems. After all, one of their jobs is to make sure that computers used by the U.S. Department of Defense are secure against determined attackers. The NSA found that most operating systems' security mechanisms, including Windows and most UNIX and Linux systems, only implement "discretionary access control" (DAC) mechanisms. DAC mechanisms determine what a program can do based only on the identity of the user running the program and ownership of objects like files. The NSA considered this to be a serious problem, because by itself DAC is a poor defense against vulnerable or malicious programs. Instead, NSA has long wanted operating systems to also support "mandatory access control" (MAC) mechanisms.

MAC mechanisms make it possible for a system administrator to define a system-wide security policy, which could limit what programs can do based on other factors like the role of the user, the trustworthiness and expected use of the program, and the kind of data the program will use. A trivial example is that with MAC, users can't easily turn "Secret" into "Unclassified" data. However, MAC can actually do much more than that.

The NSA has worked with operating system vendors over the years, but many of the vendors with the biggest markets haven't been interested in incorporating MAC. Even the vendors who have incorporated MAC often do it as "separate products," not their normal product. Part of the problem was that old-style MAC just wasn't flexible enough.

NSA's research arm then worked to try to make MAC more flexible and easier to include in operating systems. They developed prototypes of their ideas using the Mach operating system, and later sponsored work extending the "Fluke" research operating system. However, it was hard to convince people that the ideas would work on "real" operating systems since all this work was based on tiny "toy" research projects. Few could even try out the prototypes, to see how well the ideas worked out with real applications. NSA couldn't convince proprietary vendors to add these ideas, and NSA didn't have the right to modify proprietary operating systems. This isn't a new problem; years ago DARPA tried to force its operating system researchers to use the proprietary operating system Windows, but encountered many problems (see the Resources resources below).

So, NSA hit upon an idea that seems obvious in retrospect: take an open source operating system that's not a toy, and implement their security ideas to show that (1) it can work and (2) exactly how it can work (by revealing the source code for all). They picked the market-leading open source kernel (Linux) and implemented their ideas in it as "security-enhanced Linux" (SELinux). Not surprisingly, using a real system (Linux) made the NSA researchers deal with problems they hadn't had to deal with in toys. For example, on most Linux-based systems, almost everything is dynamically linked, so they had to do some subtle analysis about how programs are executed (see their documentation about the "entrypoint" and "execute" permissions for more information). This has been a far more successful approach; far more people are using SELinux than the previous prototypes.

Recommended Links

Softpanorama Recommended

Top articles

Sites

The Jail Subsystem Chapter 4 of FreeBSD Architecture Handbook. By Evan Sarmiento

Daemon News Inside Jail by Evan Sarmiento

On most UNIX systems, root has omnipotent power. This promotes insecurity. If an attacker were to gain root on a system, he would have every function at his fingertips. In FreeBSD there are sysctls which dilute the power of root, in order to minimize the damage caused by an attacker. Specifically, one of these functions is called secure levels. Similarly, another function which is present from FreeBSD 4.0 and onward, is a utility called jail. Jail chroots an environment and sets certain restrictions on processes which are forked from within. For example, a jailed process cannot affect processes outside of the jail, utilize certain system calls, or inflict any damage on the main computer. Jail is becoming the new security model. People are running potentially vulnerable servers such as Apache, BIND, and sendmail within jails, so that if an attacker gains root within the Jail, it is only an annoyance, and not a devastation. This article focuses on the internals (source code) of Jail and Jail NG. It will also suggest improvements upon the jail code base which are already being worked on. If you are looking for a how-to on setting up a Jail, I suggest you look at my other article in Sys Admin Magazine, May 2001, entitled "Securing FreeBSD using Jail."

Sys Admin MagazineSecuring FreeBSD Using Jail

Editor's note: This article discusses a project that gives root access to anyone who wants it. The OpenRoot project operates in a virtual machine and uses FreeBSD's Jail feature. This author's implementation of OpenRoot is intended for training and experimentation purposes only. The practice of giving out root to all comers (with or without a Jail) is too risky for most environments, however, this article provides useful information.

I started a project called Openroot, where I give root access to anyone on a box on my network. In this environment, users, mostly students like me, can learn, experiment, install software like Apache and Sendmail, or tinker around with configuration files to see how they work. However, this project was mostly intended to help me learn, in-depth, about UNIX security procedures. I've taken many precautions, which can not only help you secure a UNIX system like this one, but may also help secure general-purpose UNIX systems. Primarily, I used a feature present in FreeBSD from versions 4.0 and onward called Jail.

Essentially, Jail creates a process tree exclusively for itself. Processes inside the Jail cannot affect processes outside. Thus, by recreating the base system files inside a Jail, it acts like an independent computer (see Figure 1).

A Jailed environment, of course, has some restrictions. For example, users inside a Jail cannot kill processes outside or harm the actual computer; users inside a Jail cannot mount filesystems or delete partitions using fdisk. Most importantly, users cannot use system calls that could enable them to break out of the Jail. Therefore, Jail was a godsend for my Openroot project. If someone typed "rm -rf /", it could ruin the experience for everyone, because all Openroot users use the same Jail. But an auto-restore script running on the host computer restores the Jail every hour. In this article, "$D" will always stand for the Jail's directory and "$IF" for interface name, and so on.

Jails: Confining the omnipotent root.Poul-Henning Kamp <[email protected]> Robert N. M. Watson <[email protected]> The FreeBSD Project

FreeBSD Process Management By George Neville-Neil, Marshall Kirk McKusick. Sample Chapter is provided courtesy of Addison Wesley Professional.

The Jail Facility in FreeBSD 5.2 by Kirk McKusick (PDF)

Daemon News Inside Jail by Evan Sarmiento < [email protected] >

JailNG?: http://www.watson.org/~robert/freebsd/jailng/

How to break out of a chroot jail: http://www.bpfh.net/simes/computing/chroot-break.html

http://open-root.org

http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/jail.html

http://www.samag.com/documents/s=1151/sam0105d/0105d.htm

Problems

PostgreSQL running in FreeBSD jail corrupts PostgreSQL running on ...

• From: Bill Moran <wmoran ( at ) potentialtech ( dot ) com>
• To: psql-general ( at ) postgresql ( dot ) org
• Subject: PostgreSQL running in FreeBSD jail corrupts PostgreSQL running on the host system
• Date: Tue, 27 Jul 2004 08:38:39 -0400

---

I'm having some problems.  Hopefully there are some FreeBSD folks here
that can help me out, if not, I'll try the FreeBSD lists next.

I'm running Postgres 7.4 installed from a just cvsupped FreeBSD ports.
I've got a production machine that's going to need a lot of upgrades, and
I want to test them out prior to upgrading the production environment.
So I built a jail on the production machine to install the new software
in and test prior.  Seems logical, right?

Anyway, I set security.jail.sysvipc_allowed=1 so Postgres can run in the
jail, but every time I start Postgres in the jail, the Postgres running
in the host environ goes wacky.  If I try to connect with psql, I get
the following error:

psql: FATAL:  semctl(65542, 0, SETVAL, 0) failed: Invalid argument

This is FreeBSD 5.1-p17 (I can't upgrade to 5.2.1 until the em driver is
fixed ... but if someone knows for sure that this is fixed in 5.2.1, I'll
push harder to get that driver fixed!)

Anyone have any idea what's going wrong here?  Or what I can do to fix
it?

-- 
Bill Moran

Postfix in a FreeBSD jail barnson.org

I recently ran into problems with postfix running inside of a FreeBSD jail. It would constantly report "file too large" errors, and other errors in that vein. Since there appears to be no documentation for FreeBSD "newbies" on fixing this problem, it seems like most people default back to sendmail or exim, rather than using the excellent Postfix MTA on their virtual file systems.

I love postfix, so that is a situation I'd like to change! Here are the directions on how to get postfix working inside a FreeBSD "jail" system.

Well, the basic problem with Postfix in a FreeBSD 4.8 jail is the disconnect in the setrlimit() call in Postfix versus the kernel. You end up with spurious "file too large" errors when sending and receiving messages, which just sucks.

There's a patch at http://www.kozubik.com/published/misc/postfix_patch_fbsd45jail

Here's how I do this without using the above patch:

IMPORTANT NOTE: A generous reader left a clarification

Random Findings

User Mode Linux: http://usermodelinux.org/

Im experiencing huge problems running jails on FreeSBD 5.2.1-RELEASE on
i386. First of all - not clear documentation for devfs rules and rc files
tunning. But whatever... The problem... rc.conf contains following setting for jail:

# jails
jail_enable="YES" # Set to NO to disable starting of any jails
jail_list="host2" # Space separated list of names of jails
jail_set_hostname_allow="YES" # Allow root user in a jail to change its
hostname
jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail

jail_host2_rootdir="/usr/jails/host2" # Jail's root directory
jail_host2_hostname="host2.avdos.com" # Jail's hostname
jail_host2_ip="xx.xx.xx.xx" # Jail's IP number
jail_host2_exec="/bin/sh /etc/rc" # command to execute in jail
jail_host2_devfs_enable="YES" # mount devfs in the jail
jail_host2_procfs_enable="YES" # mount procfs in jail
jail_host2_devfs_ruleset="4" # as described in
/etc/defaults/devfs.rules

well... looking on /usr/jails/host2/dev after restart:
su-2.05b# ls /usr/jails/host2/dev
acpi ad8s1d consolectl klog null
ttyd1 ttyv6
ad4 ad8s1e ctty kmem pci
ttyid0 ttyv7
ad4s1 agpgart cuaa0 lpt0 ppi0
ttyid1 ttyv8
ad4s1a apm cuaa1 lpt0.ctl ptyS0
ttyld0 ttyv9
ad4s1b ar0 cuaia0 mdctl ptyp0
ttyld1 ttyva
ad4s1c ar0s1 cuaia1 mem ptyp1
ttyp0 ttyvb
ad4s1d ar0s1a cuala0 net random
ttyp1 ttyvc
ad4s1e ar0s1b cuala1 net1 stderr
ttyv0 ttyvd
ad8 ar0s1c devctl net2 stdin
ttyv1 ttyve
ad8s1 ar0s1d devstat net3 stdout
ttyv2 ttyvf
ad8s1a ar0s1e fd net4 sysmouse
ttyv3 urandom
ad8s1b ata geom.ctl network ttyS0
ttyv4 zero
ad8s1c console io nfs4 ttyd0
ttyv5

yep... where is devfs filter????
OK.. lets make this directly form script:
---------------------------------
#!/bin/sh
# jail devfs
/sbin/devfs rule -s 10 delset
/sbin/devfs rule -s 10 add 100 hide
/sbin/devfs rule -s 10 add 200 path 'ptyp*' unhide
/sbin/devfs rule -s 10 add 300 path 'ttyp*' unhide
/sbin/devfs rule -s 10 add 400 path null unhide
/sbin/devfs rule -s 10 add 500 path zero unhide
/sbin/devfs rule -s 10 add 600 path random unhide
/sbin/devfs rule -s 10 add 610 path urandom unhide
/sbin/devfs rule -s 10 add 700 path fd unhide
/sbin/devfs rule -s 10 add 800 path fd/* unhide
/sbin/devfs rule -s 10 add 810 path mdctl unhide
/sbin/devfs rule -s 10 add 900 path stdin unhide
/sbin/devfs rule -s 10 add 910 path stdout unhide
/sbin/devfs rule -s 10 add 920 path stderr unhide

/sbin/mount_devfs devfs /usr/jails/host2/dev
/sbin/devfs -m /usr/jails/host2/dev rule -s 10 applyset
---------------------------------

Running this script from rc.local (for example) or even manually from
cmd line will take NO EFFECT also! But look!

su-2.05b# ./devsetup
su-2.05b# ls -1 /usr/jails/host2/dev | wc -l
90

same result as we've got after rc.conf tuning... next string is just
last command from script ./devsetup described above:

su-2.05b# /sbin/devfs -m /usr/jails/host2/dev rule -s 10 applyset
su-2.05b# ls -1 /usr/jails/host2/dev | wc -l
13
su-2.05b# ls /usr/jails/host2/dev
fd mdctl null ptyp0 ptyp1 random stderr stdin stdout
ttyp0 ttyp1 urandom zero
su-2.05b#

What the %&#K ??? Script not works, but direct commands from command line working properly! Any ideas?

Alexander Voronin

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019