Quoting Stephen Smalley (sds@xxxxxxxxxxxxx): > > On Wed, 2008-03-26 at 09:32 +1100, NeilBrown wrote: > > 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> > > Containers can be useful, but they aren't a substitute for access > control, and they don't solve the same problem. Not only that, but containers require an LSM to provide user isolation and root containment. Hopefully at some point we'll be able to get around that for most VPSs, but that's a long ways off and personally I suspect I would always want a policy locking VPSs up nice and tight. > And SELinux does get used, and recent stats on Fedora 8 suggest that few > people disable it anymore. Advances in the SELinux tools (loadable > modules, semanage, system-config-selinux, setroubleshoot, etc) have gone > a long way to enabling users to solve problems they encounter. > > -- > Stephen Smalley > National Security Agency > > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
