On Friday 29 February 2008 07:32, James Antill <james.antill@xxxxxxxxxx> wrote: > > > What does open on a dir mean? Isn't that the same as the read perm? > > > > Admittedly there is very little distinction and I don't know the > > usefulness, but it is possible for a process to pass an open fd to a > > directory so I saw little reason to exclude it. > > Also we have the *at() and fchdir() calls, so this distinction (between > open and read on dirs) is useful. This new open permission is being created specifically to allow file handles to be inherited across exec. Inheriting a directory file handle for the purpose of fchdir() seems quite unlikely. In fact when fchdir() is mentioned in mailing list discussions it always seems to be in the context of allowing a process to break out of a chroot() jail. Does anyone have a hypothetical example of how fchdir() could be used in a way which doesn't break the security of a system but yet need to have open and read access be differentiated? As an aside, I'm concerned about the implications of this new file open permission for overall quality of SE Linux policy (both reference policy and custom policy). I anticipate many people writing policy that allows read and write access wildly with the idea that controls on open will prevent them being exploited. -- russell@xxxxxxxxxxxx http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
