← Back to context

Comment by egberts1

7 days ago

Shoot. Almost there, at least for us cybersecurity-minded folks.

A need for a default-deny-all and then select what a process needs is the better security granularity.

This default-ALLOW-all is too problematic for today's (and future) security needs.

Cuts down on the compliance paperworks too.

3 comments

egberts1

Reply
westurner  7 days ago

DAC: Discretionary Access Control: https://en.wikipedia.org/wiki/Discretionary_access_control :

> The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).

Which permissions and authorizations can be delegated?

DAC is the out of the box SELinux configuration for most Linux distros; some processes are confined, but if the process executable does not have the necessary extended filesystem attribute labels the process runs unconfined; default allow all.

You can see which processes are confined with SELinux contexts with `ps -Z`.

MAC is default deny all;

MAC: Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control

  • egberts1  4 days ago

    Biggest problem is the use of a SELinux compiler into components understood only by SELinux engine.

    Does not help when the SELinux source text file is not buildable by function/procedure axiom: it is at its grittiest granularity, which ironically is the best kind of security, but only if composed by the most savviest SELinux system admins.

    Often requires full knowledge of any static/dynamic libraries and any additional dynamic libraries it calls and its resource usages.

    Additional frontend UI will be required to proactively determine suitability with those dynamic libraries before any ease of SELinux deployment.

    For now, it is a trial and error in part on those intermediate system admins or younger.

    • westurner  4 days ago

      From > [ audit2allow,