* richard offer (offerat_private) wrote: > > > I spent a just a few minutes looking, and its not sufficient simply to > override the return of capable, the value returned would have to be > dependent on what capability was being checked, returning zero for some > values, doing a real capable check in others. > > And we'd still have to move the in-kernel code into the module to capture > the error code as there are places that return different errno's depending > on the code path. > > Problems > > vfs_permission() > sys_setpriority() > sys_setgroups() > sys_sethostname() > sys_setdomainname() great, this is a really useful info. so my cursory look shows that: sys_setgroups, sys_sethostname, and sys_setdomainname had this problem in the authoritative patch. hence the move of the capable() call in the authoritative patch to after the copy_from_user. so i believe the same move would allow you to use the capable override. sys_setpriority you'd definitely have to re-create the in-kernel check in the module, but it still looks do-able to me. vfs_permission, i assume you mean permission() and getting the return value from vfs_permission as it's called in permission(). the vfs_permission function besides philosophical questions regarding immutable file and read-only filesystem checks being functional logic or access control logic...the vfs_permission function is effectively controlled by capable(). so you can override vfs_permission and you'll enter the lsm hook in permission. yes in this case you'd have to recalculate the in-kernel checks because capable is called twice in vfs_permission. so far i can't say i've seen anything that makes the capable override mechanism absolutely impossible. it's easy to argue that the permissive hook followed by a restrictive hook == an authoritative hook. if there are no cases where the capable override mechanism absolutely fails, then we are back to deciding based on the merits of just how ugly is that hack (i.e. how many hoops do you have to jump through to actually uses it) vs. how ugly is the autoritative patch (i.e. is it likely to be rejected). seems like we're making progress ;-) -chris _______________________________________________ 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 : Wed Sep 05 2001 - 19:04:00 PDT