On Thursday 30 October 2008 1:17:32 pm Eric Paris wrote: > On Thu, 2008-10-30 at 12:46 -0400, Paul Moore wrote: > > On Thursday 30 October 2008 11:29:40 am Serge E. Hallyn wrote: > > > Quoting Eric Paris (eparis@xxxxxxxxxx): > > > > Add a new capable interface that will be used by systems that > > > > use audit to make an A or B type decision instead of a security > > > > decision. Currently this is the case at least for filesystems > > > > when deciding if a process can use the reserved 'root' blocks > > > > and for the case of things like the oom algorithm determining > > > > if processes are root processes and should be less likely to be > > > > killed. These types of security system requests should not be > > > > audited or logged since they are not really security decisions. > > > > It would be possible to solve this problem like the > > > > vm_enough_memory security check did by creating a new LSM > > > > interface and moving all of the policy into that interface but > > > > proves the needlessly bloat the LSM and provide complex > > > > indirection. > > > > > > > > This merely allows those decisions to be made where they belong > > > > and to not flood logs or printk with denials for thing that are > > > > not security decisions. > > > > > > > > Signed-off-by: Eric Paris <eparis@xxxxxxxxxx> > > > > > > Please introduce some meaningful defines instead of passing 0 and > > > 1. I.e. > > > > > > #define CAP_NOAUDIT 0 > > > #define CAP_AUDIT 1 > > > > > > Otherwise, looks fine. > > > > As a general rule aren't boolean arguments like this frowned upon, > > with variations on the function preferred, i.e. something like > > below? > > > > int cap_capable(struct task_struct *tsk, int cap); > > int cap_capable_audit(struct task_struct *tsk, int cap); > > Well from outside the "security" subsystem people should call either > > has_capability() > has_capability_noaudit() > or > capable() (which calls has_capability()) > > How far down do I have to keep duplicating functionality to avoid > booleans? Probably not this far :) Sorry, reading mail too quickly ... -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
