SELinux/MAC and DAC Permissions

I am putting it in 2 points :

SELinux rules apply after DAC permissions.

Example quote from RH documentation says a Rule permits httpd process to access related web directories and files (/var/www/html & others) , while there is No rule for it to access /var/tmp, /tmp, so it cannot access these.

My point of confusion is that, any process while running, inherits and checks permissions of the user running the process and also use this to access any directories and folders.

httpd runs as root initially and then as other user www-data/apache .

Folders /var/www/html & others already have access permissions for root (rwx) and www-data/apache (r_x)

So what’s the use and role of SELinux Allow rule on this when the same purpose is being solved by DAC permissions (and DAC have precedence over SELinux rules)

Documentation says that SELinux rules/policy are checked after DAC and If DAC is denying then , it doesn’t matter if SELinux rule allows or deny it, as it won’t be checked.

So does this simply imply that SELinux rules are only useful when DAC allows but we want SELinux to block it.

Because in other 2 cases below, we have already DAC permissions doing our job.

(DAC –> allow, SELinux needs to allow)
(DAC –> deny, SELinux needs to deny),

So, lemme avoid AI generated reposes or likes, altho they are correct

Think of Selinux as a role / RBAC system.

Lets say someone compromises your buggy app, or anything else running on your system and creates a evil program in /tmp - where it can write by default in most operating system defaults.

Then it looks for bugs in your web app which does executions of any kind, e.g abused system calls, shellouts, scripts or likes .. mostly bad practices, looking for a way to execute that program created in /tmp or able to just invoke via web call.

This can be any other user on multiuser linux/unix environment running service or just ssh session.

Selinux would stop this, while regular permission would not, due to RBAC not allowing you to write on such file system even tho DAC rules allow it, effectively acting as a last resort defense against such attack surface - bugs in code, bad practices etc.

Kind of bad example, but hopefully enough to shed a light.

So even if you can create a file on your system as user, you cannot set a context to it but you can set world permissions. Context (allow apache to read file) can only be set by superuser (root) as a trusted/audited user to make such change.

As for second example, yes, if you deny something by DAC, selinux codepath is not used.

But in case DAC allows (/tmp folder) → selinux can deny or allow - per administrator configuration so it will enter the selinux codepath.

In general using only DAC, you can harden the file system access to a maximum degree of isolation - think chroot for instance.

But you still have port(s) to secure and other stuff, hence the selinux whitelist approach for every possible level (network, filesystem, devices on system access etc.)

Regards

Peasant.

Hello Peasant,

Thank you for your detailed response.., I was expecting a response and your reply was here.
It was nicely explained .
I am really a novice , new to SELinux and so clearing my concepts.
I still have lot of questions that are confusing me. Below are my present questions that pop-up
I hope you would help

1. httpd runs as root user and www-data/apache user.
   Root user already have all access to /var/www/html/ through DAC
   But www-data/apache as other user didn’t have it via DAC., So does this RBAC allow-rule for httpd was just to give access to www-data/apache users .
   Because root user already had access to /var/www/html via DAC.

2. Is RBAC necessarily about processes+ files or it applies to basic file/directory permissions/all such other scenarios also.

3. If its about all scenarios, then does it means there will be automatically made and will exist a respective Default RABC deny rule for all DAC permissions counterparts we create ( as per the nature of RBAC to deny everything by default unless allowed.)

Sincerely

Yes, DAC alone can give full safety. But it is hard to control/check, because the rules are stored in the inodes, scattered over the filesystem(s).
While SELinux has a central rule table.

@MadeInGermany ,

Thanks

I am still unclear how RBAC and DAC work together.

Can you please explain with my below 2 example scenarios :

/-------------------------------------------/

Taking /var/www/html/ access :

root and www-data/apache users already have access to /var/www/html/ via DAC, in first place (wherein www-data/apache have only read-execute)

e.g. scenario 1:
If suppose intrusion happens as root, what the intruder will do is to just add DAC write permission to this, to be able to write to it. But how this will bring RBAC to action as DAC will still be overriding it. System doesn't know if intruder is changing the DAC permission or real root

e.g. scenario 2:
If suppose, some script gets access to this folder, then that will be executed by intruder as an other user (as per DAC allowance), so again how RBAC rule comes in action.
Moreover, RBAC is again setting an allowance-rule to this which are allowing the things not denying it

/---------------------------------------------/

Also, I would really appreciate if you clear about my points 2 and 3 of my last response.

SELinux adds another restriction(safety layer) for accessing files.

With RBAC the focus is on roles. A role can elevate rights for certain tasks. A user or group gets additional kernel-controlled rights.
RBAC is a better alternative to the well-known sudo that elevates to the almighty UID 0 then in user-space restricts to certain commands.
Tasks can be more than commands.
IMHO Linux policity kit (polkit) is close to RBAC, but is implemented in user space.

Thanks for reply. Yes I got the point that Tasks (services and daemons) are more than simple commands/tasks, and this is what is RBAC context is for.
You said it all right.

As I struggled somewhat more with topic on internet, I have got some insight how it actually works.

Thanks for all the help