On Wed, Jun 29, 2005 at 01:58:40PM -0500, serue@private wrote: > > Rather than in the case of vm_enough_memory: > > if (!capable(CAP_SYS_ADMIN)) > > free -= free / 32; > ... > > However nothing stops other code from calling capable in the second form above. It would be nice to have a mechanism to differentiate between the two forms > > though clearly this isn't an issue with stacker. > > But in either case, you are asking whether the process is > privileged, right? Or am I misunderstanding your point? True, but you do distinctly different things with the result. Is using the result to alter memory commit an access control decision? Perhaps. Using capable as the basis for rejecting a request entirely certainly is. > The way I see it, if you call capable(CAP_SYS_ADMIN), you might be > trying one of two things. > > Either you want to ask your own code for cap_sys_admin perms, > in which case you want to call my_capable(), or, more likely > you really want a finer-grained version of cap_sys_admin, and you My hypothetical concern was with other code (say totally outside of the security module arena) which wants to make decisions about two permissable paths of operation rather than allow/reject via the result of capable (or any lsm hook for that matter). It also has nothing to do with CAP_SYS_ADMIN per-se, or decomposing it, any capability will do, it just happened to be CAP_SYS_ADMIN in this case. You can also replace capable(x) with new_x_hook, but you still lack that useful bit of information about the intent of the operation to make an informed decision about whether your modules function should generate an audit. I don't have a good idea for a solution, flag to capable, *fugly*, whole new hook, 'capable_query' to indicate that the request is one where the result will not be used to generate a fundamental denial of access. Don't much like that either, plus it isn't an issue limited to capable. Clearly, you can't intelligently audit from a module since you have no idea as to what use the caller intends to make of your information (or down the road if stacker was to do something different from RETURN_ERROR_IF_ANY_ERROR). Calling capable(x) (esp. CAP_SYS_ADMIN, since it's so overloaded) from your own code to perform module specific privilege checking is something better done thru an entirely different mechanism IMHO. Tony
This archive was generated by hypermail 2.1.3 : Wed Jun 29 2005 - 13:06:51 PDT