Here's my promised second message. When I created my patch, I realized that there's a minor problem with the automatic filling in of functions done by security_fixup_ops() (defined in dummy.c, and called by security.c). The current fill-in approach presumes that any undefined functions should be set as though the module is a primary module (specifically, dummy's). However, a secondary module should have absolutely no effect unless it's defined by its security policy. That way, users can use the capability module, or a replacement for the capability module, or something entirely different. Otherwise, users get "stuck" and can't stack, say, owlsm with capability2. Currently, a secondary must always override the dummy functions that do anything: capget, capset_check, capable, netlink_send, netlink_recv, task_reparent_to_init, and ip_decode_options. These need to be overridden with "noop" operations, instead of what dummy does. It's not a great hardship to override 7 fuctions with a no-op, and then define the no-op, but it's unnecessary. Instead, security_fixup_ops() should fill in different values if the module is a secondary. This involves a small amount of additional code, but it would make things much more likely to "just work" and it would make secondary-aware modules much simpler to write. For simple modules that especially important; half of my patch was to deal with the "wrong default" problem. If the defaults were "correct", making a module work as a secondary module is actually pretty simple! Comments? Am I all wet? --- David _______________________________________________ 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 Dec 20 2002 - 19:58:47 PST