Is it MAC or DAC

Question

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.

Answer 1

Capabilities are a privilege escalation layer similar to setuid, but a lot more fine grained; eg a program could gain CAP_NET_RAW privileges without having full root level access. It's a big step forward for "minimum necessary privileges" and control of a server, so it's good, but it's not a Mandatory Access Control; it's a privilege escalation.

SELinux works on the concepts of labels and permissions between labels. So you might grant the httpd process the "web server" label, all the files inside the web tree the "web files" label and then grant "web server labelled processes can read web files and nothing else".

This labeling construct sits above the existing file system permissions and ACL permissions. Even if a file is world readable, SELinux can deny access to it. For a process to be granted access it needs to pass both DAC (filesystem permissions) and MAC (SELinux) permissions.

From the commercial side of the world, eTrust Access Control (or Control Minder, or whatever it's called these days; originally SEOS) is another MAC layer. This doesn't use labels to control stuff but allows path defined rules and will checksum programs if they're used in a rule. This is more flexible than SELinux labels (and is cross-platform; eg Solaris, AIX, HPUX). Again this sits above the filesystem DAC layer; both need to approve the request.