On Tue, Sep 02, 2003 at 10:38:08PM -0400, Valdis.Kletnieksat_private wrote: > On Tue, 02 Sep 2003 18:54:31 EDT, Charles Levert said: > > > Here is what I am trying to do. Let d be a reference directory that > > is an open file of the current process (i.e., it has a file descriptor > > assigned to it). Let f be the file that the user is trying to open > > (or an executable that he's trying to execute) after all symlinks have > > been traversed. The open is allowed to succeed if f is in the subtree > > of files specified by d. E.g., > > > > d=/a/b f=/a/b/c/d succeeds > > d=/a/b f=/a/e/f fails > > > > For this, I need to be able to walk the tree from f to the root and if > > I pass by d in doing so, then the open succeeds. > > And how is this better than just doing a 'chroot("/a/b");'? This is more flexible: you can manipulate more than one "d", which are effectively interpreted as being (traditional) capabilities. You do not need to set up a jail with a copies of the libraries and all. I plan to have a /cap pseudo-filesystem populated with files that take a special meaning according to their path name (e.g., /cap/user/alice/work or /cap/proto/tcp/peer_port=80). I have also some IPCs where you can send a capability to another process, or also just brag about possessing one without handing it over to the other process. I am trying to come up with something that would allow anybody with a Linux system to experiment with a capability system now, while other systems such as EROS are being completed. This is mostly an experimental effort that requires applications to use a partly new API. I don't claim at all that this is compedition to, e.g., SE Linux, that aims to secure existing applications with minimal impact on the API. It is a platform prototype aimed at investigating the consequences of using capabilities. Charles _______________________________________________ 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 : Tue Sep 02 2003 - 20:40:39 PDT