Is it MAC or DAC

I am having trouble seeing the utility or use of the LSM attribute/caps implementations. I've put together a pseudo code snippet of sorts to try to express my concern and question. It's modeled after a diagram from (p 3) https://www.kernel.org/doc/ols/2002/ols2002-pages-604-617.pdf Kernel access check (approx) and LSM call: DAC op:__? // ? what operation would pass a DAC check yet not the LSM hook ? file:___ perms: u.. g.. o.. euid:100 egid:500 OK ----> LSM hook ( args ) 1) I don't know the args here, 2) Regardless of the args I can't make out what operation would pass a DAC check and be restricted here and why? ? read file ? allready handled by DAC ? network device ? allready handled by DAC, it's a file. ? execution ? x bit , allready handled ? executing a specific function ? no function call references here ? executing a specific syscall ? would be handled on exec on the target (read, write etc..) ? **What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??** Answers are welcome. sp I've read talk about attempting to have coders not use setuid root and use some CAP attribute instead to make this work for safer privileged escalation but I'm personally not a pundit for relying on a change in behavior nor a hook permissions check to assure the integrity of code running on a machine and I doubt I'm alone. I've also read it's not the intent of LSM here which addresses the design yet remains vague on precise uses over the current DAC permissions checks. It talks about why the hooks are where they are but not how to use them effectively to, again, accomplish something more than DAC.