On Thu, Nov 15, 2007 at 11:30:16AM -0800, Clarkson, Mike R (US SSA) wrote: > Is there a compelling reason to protect the getattr permission with mls > constraints? > > The RHEL5 policy treats the gettattr the same way read is treated with > respect to mls constraints. What information that may be classified is > being protected? The only thing that I can think of is the file name, > and you need the file name to get the attributes of the file anyway (or > maybe there is a way to get the attributes using only the inode?)
User-specified extended attributes can store arbitrary textual data when used according to the interface documentation, so this information needs to be protected by the MLS rules. An alternative would have been to disable user-defined extended attributes completely. The "functional specification mapping" document explains the logic used for classifying system calls and other interfaces. As far as I know it's currently only available as part of the test case source archive: http://downloads.sourceforge.net/ltp/rhel5_ibm_eal4_cert_suite2.tgz?modtime=1187697700&big_mirror=1 See the "System Calls" sheet (copied below): The following rules were used to determine if a system call is security relevant: TSF object access DA and MA and RBAC read/write/execute of object contents (including device files holding or transporting data, including tmpfs) DA or MA or RBAC write object metadata holding security information (such as file mode bits, ACL, SELinux type, MLS label), depending on which policy is affected by the metadata MA read/write metadata containing user defined strings (including filenames, textual extended attributes, environment variables (/proc/$PID/env); IPC objects don't have any such metadata) none read/write/execute any other object metadata that does not contain user data (including utime, virtual files (/proc, /selinux)). These are potential covert channels for MA, but this is not relevant for LSPP which does not include covert channel analysis. Any system feature that supports storing user data or communication must be covered by the MAC policy or alternatively must be disabled in the evaluated configuration (includes kernel keyring, processes/signals). For labeled networking, the policy must ensure that TCP sessions are only established if the MLS labels of both endpoints are equal, which ensures that an open file descriptor implies that communication is permitted by the MAC policy. -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
