Hi Stephen, Imagine you have two processes, say A and B, running with different security contexts. If A opens a file and passed the file descriptor to B (sends it over an AF_UNIX socket perhaps), then what security context should be assumed when B operates on the file descriptor? A's security, or B's?
I would have thought it should be A's security, since A opened the file. This is usually the case for UID/GID/mode information (which are resident on the file struct) and other FS-specific access contexts (in the in-kernel AFS's case, this includes the kerberos ticket A used to access the file, and I believe the same is true in NFS's case). However, having just been looking through security/selinux/hooks.c, this isn't always the case with SELinux. For ioctls, for example, B's security context will be used. The same goes for reading and writing. This is surely incorrect. This can mean A can pass a file that it can read and write to B that B can't then read or write because it doesn't have access, even though it ought to be able to because *A* can. At least, that's how I interpret the code. If I'm right, and this is incorrect behaviour, then I have most of a patch that I'm working on to pass the appropriate credentials around. David - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
