chown() system call. The owner and the root user are allowed to define and change access rights for an object.
This following subsection looks at the kernel functions implementing the access checks. The function used depends on the file system; for example, vfs_permission() invokes permission() which then calls specific *_permission() routines based on the inode’s inode operation vector i_op. proc_permission() is called for files in procfs. ext3_permission() is called for the ext3 disk- based file system. If no file system specific *_permission() routine was registered, generic_permission() is called to perform the access checks. For some file systems including ext3, the specific *_permission() routine invokes generic_permission(). Note that access rights are checked when a file is opened and not on each access. Therefore, modifications to the access rights of file system objects become effective at the next request to open the file.
AppArmor may optionally be loaded. AppArmor additionally restricts which files certain programs may access. AppArmor is controlled by profiles in the /etc/apparmor.d directory. When loaded, AppArmor applies additional restrictions to ping, syslogd, klogd, netstat, traceroute, lld, named, identd, nscd, ntpd, and mdnsd. Additional profiles may be created by an authorized administrator. AppArmor can run without affecting the TOE security functions because AppArmor will only add restrictions, it will not allow what is denied. Whenever DAC denies an operation, AppArmor is not even consulted.
5.1.5.1Permission bits
generic_permission() implements standard UNIX permission bits to provide DAC for file system objects for the procfs, devpts, sysfs, tmpfs, securityfs, binfmt_misc, and ISO 9660 file systems. As noted in Section 5.1.3.5, there is no mechanism for accessing rootfs.
The ext3 file system uses the permission bits for files that do not have associated ACL information. This is implemented in the generic_permission() function.
There are three sets of three bits that define access for three categories of users: the owning user, users in the owning group, and other users. The three bits in each set indicate the access permissions granted to each user category: one bit for read (r), one for write (w), and one for execute (x). Note that write access to file systems mounted as read only, such as CDROM, is always rejected. Each subject’s access to an object is defined by some combination of these bits:
rwx | indicates read, write, and execute |
indicates read and execute | |
indicates read |
---indicates null
When a process attempts to reference an object protected only by permission bits, the access is determined as follows:
•Users with an effective user ID of 0 are able to read and write all files, ignoring the permission bits. Users with an effective user ID of zero are also able to execute any file if it is executable for someone.
•If the file system UID equals the
•If the file system GID, or any supplementary groups of the process equal an object’s owning GID, and the owning group permission bits allow the type of access requested, access is granted with no further checks.
47
