[WARNINGS] link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1 link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3 link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5 link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7 link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8 link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10
Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B
I)
h1. Chapter 11: Security
("Those willing to give up a little security by using a little obscurity deserve neither security nor root privileges." - B. F.)
Not everyone wants their private information accessed or altered by others. Were this allowed to happen, credit card numbers and other identity information could be stolen.
In much the same way, not every process wants their "private" information accessed or altered by any other random process. Were this allowed to happen, then system integrity would be compromised.
For these reasons, security measures are a must.
h2. 1. Basic Security Measures
Security within memory is covered via protections. This is discussed in Chapter 5: Memory Management under Page Protections. These protections basically allow processes to protect their memory by terms of non-readable, read-only, non-executable, etc. The kernel must honor these privileges to ensure system integrity.
Security among other objects, such as files and processes, is usually handled using Permissions, ACLs, or Capabilities.
h4. Permissions
These are used in UNIX and Linux. Users each have their own user ID, or uid. There are also groups that users can be part of. There are usually groups such as @audio@ or @cdrom@, which allow all members of each group access to those resources. Therefore, each user has their own uid and a list of gids (group ID) of which they are members.
The i-node of each file in UNIX has its own uid and gid, as well. The uid is of the file's owner, and the gid is whatever is assigned to the file. Also in the i-node is a 9 bit list of permissions. These permissions are readable, writable, and executable (@r@,@w@,@x@). The 9 bits are divided into three groups of three. The three bits in each group stand for @rwx@, in that order. The first group of three represent the permissions of the owner. The next three are for the users that belong to the file's group. The final set of three represent the permissions for everyone else, or other. This owner/group/other system is part of the POSIX standard.
Take the following files, for example:
rw-r--r-- 1 dimitri users 515 Aug 1 2005 notes rwxrwx--- 1 dimitri users 26 Nov 22 2005 ocg
Both files are owned by the user @dimitri@ and are part of the group @users@. The file @notes@ allows the owner, @dimitri@, to read and write to the file. However, other members of the group @users@, as well as any one else for that matter, can only read the file. The file @ocg@ is executable, but only by @dimitri@ and anyone in the @users@ group.
h4. Access Control List (ACL)
An ACL is a list associated with each object. These are lists of different users and groups and their permissions to that object.
| File | Access Control List | ||
| @notes@ | @dimitri, users: RW; bob, coders: RW@ | ||
| @ocg@ | @dimitri, users: RX@ |
With this table of ACLs, the file @notes@ provides the same permissions to @dimitri@ and @users@ as it did in the Permissions example, above. However, it also provides these permissions to the user @bob@ and the group @coders@.
h4. Capabilities
In contrast to permissions and ACLs, capabilities are not contained within i-nodes, or otherwise referenced by the object being accessed. Instead, the situation is vice-versa. A process requesting the access must obtain a capability, first, and that capability is what allows references to the requested object. The requesting process does not have direct access to the requested object.
A capability can be thought of as a special admission ticket that a process uses to access what it needs. It can use this ticket (capability), delete it, or give a copy to another process of equal or lesser privilege.
These “admission tickets” can actually contain numerous capabilities at once, one for each object that process will ever need to access. These capabilities are stored in a list called the capabilities list, or C-List. Each capability in this list includes the type of object it's regarding, the rights to that object, and the pointer to the object, itself. Take the C-List below.
*@C-List1:@*
| Type | Rights | Object | |||
| File | @RW-@ | Pointer to @notes@ | |||
| File | @RWX@ | Pointer to @ocg@ | |||
| Pointer | @R--@ | Pointer to @C-List2@ |
A process could use this C-List, for example, to read or write to @notes@. The process could also use the third capability in this list to link to another C-List (@C-List2@), thereby adding on to the total available capabilities.
h2. 2. FMI/OS
FMI/OS currently uses a hierarchical ID model in conjunction with permissions. For instance, a user could have multiple uids and gids. Therefore, access to an object is the sum of access gained by each ID held (Valencia, "VSTa:").
This method was the original one used in VSTa (and was grandfathered into FMI/OS). It has many limitations, especially in regards to combinations of permissions on an object. Also, in the micro-kernel and orthogonal environment, a capabilities system would probably be more functional and secure. This is still in the hypothetical stages and no design or implementation decisions have yet been made for FMI/OS.
(c)2006 Dimitri Hammond
h4. Comment by major on Mon Dec 4 03:17:09 2006
One of the more widely use capabilities systems out there is Kerberos. Plan9 adopted a fairly Kerberos style system for authentication as well. Capabilities are better described as a user carrying around a key to unlock something. This is the case with the Kerberos model, in that a user is given a "ticket", when the user wishes to do something, it presents the ticket to a service as proof of their identity, the service then contacts the "ticket granting ticket" server to validate the ticket. Upon validation, the service then hands the user back a new ticket issued by the service, and signed by the "ticket granting ticket" service. From that point on, when the user wants access to an object from that service, they simply need to present the ticket they where given. By and large, recieving ones initial ticket in a Kerberos environment involves usage of the 'kinit' command, from there, the GSSAPI tends to take care of the rest.
The AFS and DFS filesystems are examples of ACL based systems that rely on capabilities to validate user identity. A user has a kerberos ticket, or afs token, that they carry around to verify their identity to the filesystem, from that point on the filesystem limits their access on a per-directory basis based on locally stored Access Control Lists (ACL).
One of the things to keep in mind is that experience has taught us that there is no one "true" model that fits everything. Linux, and many other Unices support the traditional bitmapped permission masks (rwx), as well as Access Control Lists on some filesystems. Further more, Linux has its own version of a capabilities system it uses for a variety of other tasks, such as granting a "future" process permission to do things to a privledged port that the process would not normally be allowed to do.
Eros is a "pure capabilities" operating system that attempted to demonstrate a "totally secure" platform. The end issue with the system though was that it fundementally couldn't run anything. The capabilities model used was effectively fine tuned to Eros, and very inflexible to any existing software.
Ultimately FMI/OS will need to be able to play with a wide variety of security options, mostly because the inability to play well with others pretty much dooms one to a lonely life of isolation. Something I don't think encourages development.
Anyway, while you covered the general principals of permission granting, you failed to cover some of the other security considerations in a platform. Jailed filesystems, restricted environments, encryption, ect.. Also, there are the various parts of a system that often lead to security issues. Plain text passwords on the network, plain text passwords on the filesystem, suid programs and buffer overflows, so on and so forth.
Anyway, just a few notes .. I am rambling when I should be porting glibc ;)
h4. Comment by dam on Mon Dec 4 12:04:16 2006
Well, I wasn't sure how much in-depth I should get in this chapter. I could mention encryption and kerberos and such, but to what detail?