On Fri, 29 Jun 2001, Serge E. Hallyn wrote: > Of course, if we ask to modify the vfsmount structure, we may be > asking too much. But if we can't do that, then perhaps we *should* > remove the other pathname-based label assignment functions, in order > to give the rest of lsm a better chance. Naturally, that is not my > preference. My take, as the guy who uses pathnames, but feels they are still the "Wrong Answer"(tm). IMHO, the 'Correct Answer' is to have an initialization stage that applies types to files via some kind of Extended Attribute mechanism. Your enforcement layer should only care about types, and basically ignore filenames. Yes, I know EA's don't exist yet. I'm talking theory here, lets not add in any annoying facts to slow things down. A very good point was raised last night at the BOF about trying to type files that do not yet exist. Apparently our DTE system hit similar problems and the hack-around they used may work. They used something they called "HADB" for Heirachical Attribute DataBase. Basically they kept a whole shadow tree of inodes in which they kept types, and while most of the shadow inodes refered to real inodes, they did not have to. So basically, You could add into your opaque security structure on the inode a tree to represent the children that do not yet exist that you want mappings for. At creation time you can look at the realitive name only to determine if this object is one you care about and assign your type tags. (For removing objects, a "is same type" test could be used to let you know if you have to re-create the shadow tree...) Questions? (I don't know if I can answer any, but that has never prevented me from making up things in the past) Comments? Doug -- dougkat_private dkilpatrat_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 Jun 29 2001 - 08:01:32 PDT