On Tue, 15 May 2001, Chris Evans wrote: > A solution is to ensure that a process _never_ gets its hands on a file > descriptor which could be used to violate security policy. This shouldn't > require too much work at all. Security-Enhanced Linux (SELinux, http://www.nsa.gov/selinux) implements controls over both the transfer of open file descriptors (via execve or sendmsg) and the use of open file descriptors (e.g. read, write, sendfile, mmap, etc). There are several reasons for controlling use as well as transfer: 1) Least privilege. Some processes may legitimately be able to hold and transfer a descriptor but have no legitimate reason to use it. Think of capability-based name servers. Likewise, some processes may legitimately be able to hold and use a descriptor but should not be able to transfer it to others. Finally, there is a mismatch between what a descriptor represents and what can be performed using a descriptor - the descriptor only expresses notions of read and write, while there are many other operations that can be performed using a descriptor (e.g. changing the immutable flag on an ext2 file via ioctl). 2) Revocation. A change in the label of a process or a file or a change in the security policy may require that existing open file descriptors be revoked. You could implement revocation at the time the change occurs, but this requires tracking down all affected open file descriptors and updating them. That isn't hard for a change in the process label, but it involves significantly more for a change in a file label or a change in the policy itself. Allowing a security module to revalidate permission on use seems desirable. Of course, memory-mapped files are more difficult to address. Since we can't really revalidate permission on use in that case, SELinux must explicitly invalidate the page cache entries of any files affected by a change in a file label or policy and then revalidate permission on the subsequent page faults. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed May 16 2001 - 06:01:34 PDT