On 27 Apr 2001 talgat_private wrote: > So there is only few ways I know of to pass file descriptors between > processes. > > Through inheritance via. fork/clone. > Through shared descriptor tables via. clone. > Through descriptor passing via. sendmsg/recvmsg. > > I don't see why these are "a lot of sloppy ways". On this point, I would tend to agree. In SELinux, we weren't concerned with fork/clone itself, since we only change process security attributes on execve, but we did provide controls over file descriptor inheritance/sharing across execve and file descriptor transfer on sendmsg/recvmsg. But we also provide controls on the use of descriptors on operations such as read and write. I'll come back to that point below. > Why?, if you want to control access at the level of granularity provided > by normal unix permissions (read/write etc.) then simply controlling > access to descriptors is fine (again modulo stuff like core dumps). > If you wish to provide finer grain control you can simply pass along more > restricted capabilities, (for example socket or file descriptors that > filter read/write based on content) and this can be implement via. > the existing device driver interface, or by passing descriptors to > user level processes which mediate access. I would have to disagree on this point. In the papers and studies published on the predecessors of SELinux (see the papers and reports accessible via the links on http://www.nsa.gov/selinux/background.html), we've argued that capability-based systems are poorly suited for enforcing security policies. Interposition by user-level processes merely extends the assurance burden to also include verifying that the user-level processes are also tamperproof, unbypassable, and correct. And even if you implement kernel controls on file descriptor inheritance and transfer (as we did in SELinux), there are still the problems of revocation and traceability of access. Even the EROS people recognized the limitations of capability-based approaches in the conclusion to their '99 SOSP paper. I think that in practice, real-world security policies seldom map well onto capability-based systems. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Apr 27 2001 - 12:08:17 PDT