IBM 10 SP1 EAL4 Manuale Utente
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
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-
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,
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
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.
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.
restrictions, it will not allow what is denied. Whenever DAC denies an operation, AppArmor is not even
consulted.
5.1.5.1 Permission 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
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
r-x
indicates read and execute
r--
indicates read
---
indicates null
When a process attempts to reference an object protected only by permission bits, the access is determined as
follows:
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.
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 object-owning UID, and the owning user permission bits allow the
type of access requested, access is granted with no further checks.
type of access requested, access is granted with no further checks.
•
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.
and the owning group permission bits allow the type of access requested, access is granted with no
further checks.
47