Manoj Srivastava <[EMAIL PROTECTED]> writes: > I would agree that no entity should be passing open file > descriptors off to other processes unless this is deliberate, and in > that case a proper policy has been written for it.
Okay, I think we're in agreement there. The only open question is what a daemon should do when it's mistakenly and erroneously handed open file descriptors by its parent process that it's not aware of (other than 0, 1, and 2, of course). Right now, some daemons close all file descriptors up to some arbitrary point (255 is common) but leave higher ones open, others try to get the file descriptor limit via getrlimit and close everything up to that limit, and others only deal with file descriptors they themselves opened. (I certainly agree that any daemon that opens file descriptors needs to handle them appropriately if it also forks -- and, of course, any daemon that uses PAM may fork. Usually by setting close-on-exec on all opened file descriptors.) >> Insofar as there is any security impact here (which is dubious in most >> cases), > Why do you say that? If a process acquires a file handle on a > privileged file while running as dpkg_t; and passes it to debconf > running as debconf_t; why is there no security impact? dpkg_t might > have more access than debconf_t in the policy being run. Well, I was thinking of the specific case that started this discussion, which as I understand it was the case of a debconf handle being left open when starting a daemon. I could be misunderstanding the problem, but if not, while this is a violation, I have a hard time figuring out what a process could do with the debconf handle. But that may just be lack of imagination on my part. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
