On Tue, March 25, 2008 10:45 pm, Tetsuo Handa wrote: > Hello. > >> Maybe some enhancement to the 'intent' structure with a similar >> effect could be done instead. >> >> Then you could, presumably, put a security hook somewhere in >> link_path_walk for those modules (like AppArmor) which want to do >> checks based on the namespace. > > I think link_path_walk() is not a good place to insert new LSM hooks > for pathname based access control (AppArmor and TOMOYO) purpose because > > (1) The kernel don't know what operation (open/create/truncate etc.) > will be > done at the moment of link_path_walk(). Though the 'indent' data structure could be used to carry this information. > > (2) Not all operations call link_path_walk() before these operations > are done. For example, ftruncate() doesn't call link_path_walk(). But do you want to impose path-name based controls to ftruncate? Surely once you have a file open for write (not O_APPEND), then no other permission is required to truncate the file, is it? If it is, then maybe the 'struct file' should be tagged at open time to say whether 'truncate' is allowed. > > (3) The rename() and link() operations handle two pathnames. > But, it is not possible to know both pathnames at the moment of > link_path_walk(). Not an insolvable problem. One could imagine an implementation where a TYPE_RENAME_FROM security check produced a cookie that was consumed by a TYPE_RENAME_TO security check. The cookie could then be used by the security module to make any connection between the two names that might be appropriate. > > I think we need to introduce new LSM hooks outside link_path_walk(). > http://kerneltrap.org/mailarchive/linux-fsdevel/2008/2/17/882024 > <rant> I suspect we would be much better off removing all the security hooks. Security done at that level seems to be way too complex such that most people don't really understand it. And people who don't understand security don't use it. We'd be much better off getting rid of the whole "micro-manage security" concept and provide isolation via some sort of high level container approach. </rant> NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
