> > > Oh, but note that the combination of security_inode_permission() and > > > security_task_to_inode() does achieve the same effect as enhancing > > > proc_pid_lookup(). It's certainly not as clean or obvious, but it might > > > be used an argument against it. Is the advantage of using this one hook > > > for both purposes sufficient motivation? > > > > Logically, I'd view "hiding /proc/pid entries" as covering both readdir > > and lookup, so I'd expect a single hook (and certainly a hook named > > task_lookup) to mediate them both. Given the existence of such a hook, > > we would implement it for SELinux to ensure consistent semantics, even > > though we already mediate lookup via security_inode_permission, as you > > mentioned. > > I agree. And I believe that pure lookup is not mediated with the > task_to_inode + inode_permission check. So, in fact, to be complete > this is required AFAICT. In fact, my experiments show the opposite to be true. Adding a security_task_lookup() call in proc_pid_lookup() causes ls /proc/1 to improperly succeed once it has properly for some other process. The task_to_inode + inode_permission check always worked. I'm guessing a third security_task_lookup() check would have to be placed in pid_revalidate(). Not sure about fd_revalidate. -serge
This archive was generated by hypermail 2.1.3 : Mon Aug 16 2004 - 18:08:21 PDT