Stephen Smalley <[EMAIL PROTECTED]> wrote: > That's how mandatory access control is supposed to work; otherwise, a > flaw in A can leak the descriptor to B at will in violation of security > policy.
Yeah, but by making it impossible to have the flaw, you've also made it impossible for A to validly pass to B a file descriptor B wouldn't otherwise be able to access directly, but should be able to access on behalf of A. To put it another way, how does A now legitimately pass on to B the grant of rights A had on that specific file descriptor? I don't think you can practically change the security attached to the file struct, With respect to execve(), imagine that program A (a shell, say) opens a file to use as a stdout for program B, which it then proceeds to exec. Imagine, however, the process's security label is changed during the exec of B and this disallows B from writing to its stdout. Is this correct behaviour since it is differs depending on whether SELinux is in enforcing mode or not? Or is there some way around this in SELinux? (I presume this is what flush_unauthorized_files() does). > And it has caught any number of bugs in applications as well as the kernel > where a descriptor is unwittingly leaked across exec. Whilst that may make it a useful debugging tool, it doesn't necessarily make it a good policy. Btw, surely selinux_file_receive() is redundant because all that it checks is whether B can naturally access the file, which surely read and write, etc, will check anyway. OTOH, although it appears to be redundant, I suppose it eliminates the use of the file as soon as possible. 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
