next up previous contents
Next: Control Requirements Up: Design Previous: Object Classes   Contents


Permissions

For each object class, a set of permissions was defined to control access to objects in that class. These permissions were identified by studying the services provided by the Linux file system component. For each service, the objects whose state is observed or modified by the service were identified, and permissions for the corresponding object classes were defined.


Table: Permissions for the pipe and file object classes.
PERMISSION(S) DESCRIPTION
read Read
write Write or append
append Append
poll Poll/select
ioctl IO control
create Create
execute Execute
access Check accessibility
getattr Get attributes
setattr Set attributes
unlink Remove hard link
link Create hard link
rename Rename hard link
lock Lock or unlock
relabelfrom Relabel
relabelto
transition


Table 8 shows the permissions defined for controlling access to the pipe object class and to the file object classes. Unlike the existing Linux file permissions, which only control the ability to open a file, the Flask read and write permissions are defined for the actual services of reading from a file or writing to a file. The implications of this stricter definition are discussed further in Section 6.1.3. A separate append permission was defined to support append-only access to a file. Whereas the existing Linux access controls permit certain services based only on the attributes of the directory, such as the service for obtaining a file's attributes and the services for adding, removing or renaming a hard link to a file, Flask provides finer-grained control through corresponding file permissions such as getattr, link, unlink, and rename. Three permissions are defined for the relabel service, since it is useful to control the relationship between each pairing of the three SIDs involved: the SID of the subject, the old SID of the file, and the new SID for the file.


Table: Additional permissions for the directory object class.
PERMISSION(S) DESCRIPTION
add_name Add a name
remove_name Remove a name
reparent Change parent directory
search Search
rmdir Remove
mounton Use as mount point
mountassociate


Table 9 shows the additional permissions defined for manipulating directories. Three separate permissions are provided for adding entries to directories, removing entries from directories and changing the parent entry (the .. entry) of a directory during a rename. In contrast, the Linux access controls use the write access mode for all three services. Two permissions are defined for the mount service, where the mounton permission is used to control the ability of a subject to mount on a given mountpoint and the mountassociate permission is used to control the relationship between the mounted directory and the mountpoint.


Table: Permissions for the file system object class.
PERMISSION(S) DESCRIPTION
mount Mount
remount Change options
unmount Unmount
getattr Get attributes
relabelfrom Relabel
relabelto
transition
associate Associate file


Permissions for controlling access to file systems are shown in Table 10. Permissions are provided for controlling mounting and unmounting and for obtaining file system attributes, such as the number of free blocks. As with files, three permissions are defined for the relabel service. The associate permission controls what files are permitted in the file system.


Table: Permissions for the file description object class.
PERMISSION(S) DESCRIPTION
create Create
getattr Get attributes
setattr Set attributes
inherit Inherit across execve
receive Receive via IPC


Table 11 lists the permissions for controlling access to file description objects. Each of these permissions is implicitly granted for file description objects with the same SID as the subject. The getattr and setattr permissions control services that observe or modify the flags and the file offset of the file description. The inherit and receive permissions control the service of inheriting descriptors across an execve and the service of receiving descriptors through IPC, respectively.


next up previous contents
Next: Control Requirements Up: Design Previous: Object Classes   Contents