by A recent discussion of separation of duties and managing the distinction between root and application code made me realize that not everyone is familiar with some of the techniques for isolating root and application.
One of the basic rules of security is summarized as separation of duties (SoD). This is sometimes called Segregation of Duties. The most commonly described element of this is separation of development from production personnel.
Unfortunately, many people appear to solve this by having all code installed as root, by the system administrator. While this prevents the developer (mostly) from altering the code, it leads to other problems in SoD. The application code becomes a root managed item which is in and of itself a problem. How do you keep that application separated from the OS? How do you ensure that the application follows the other common requirement, Rule of Least Privilege?
The Rule of Least Privilege is often stated as all tasks must be done with the minimum privilege necessary to achieve the legitimate business need. In other words, if something can be done without root, it must be done without root.
The method that I have seen work best is to ensure that there is strict separation not only between developer and production, but also between the OS support and application support roles, the system DBA from the application DBA, and so on.
Once these roles are separated, then the question becomes how to ensure that SoD above is followed.
Consider a typical system, where there are some disks available for local use, and some access to non-local disk. It may be mounted on the network (CIFS, NFS) or it may be an external storage array such as a full SAN. Any application that wishes to be installed must be installed in a directory structure that is allocated entirely for that application. For an application of any size, that directory structure is one or more file systems not on local disk.
Any application dependencies beyond base “core” items (say a POSIX environment) are to be provided by the application itself. This means providing their own java or perl binaries, not just their own libraries. By requiring them to provide their own libraries and dependencies, one avoids the maze of conflicting dependencies that block upgrades.
To ensure security on the files, each application needs to have a dedicated application account. The account owns the filesystem. Access to that account is controlled by authorized privilege escalation. The application is installed, as that ID, in the application space allocated. By mere fact of using a dedicated ID, only /tmp, individual support user’s home directories and similarly obvious places are areas that they could put files if they wanted to. So, using the example of oracle, one has oracle installed under a specific account that only the system DBAs are authorized to access.
Developers would explicitly not be on that authorized list for production, not normally. But developers could be granted access to an account and group that is carefully checked to ensure it has no more than read access. This way they can have debugging access, if appropriate.
One very positive side effect of this method is that applications now must register any network listeners that they wish to run as root. Any processes they wish to start as root must similarly be registered. This helps preserve Rule of Least Privilege.
The end result is that application code is owned entirely by application teams, installed by application teams after they obtain dedicated application accounts and directories from the system administrator. This ensures that the application team cannot run code as root without explicit permission, a good thing. Developers aren’t able to install code on production, ensuring that separation is maintained as well. Since the application is isolated from the operating system, recoverability is improved, the OS can be much more cookie-cutter because they aren’t mixed together.