Linux admin notes - security enhanced linux
| Linux-related notes
Shell, admin, and both:
Approaches to access control
Other things in the area you may wish to look at: SELinux, Tomoyo, AppArmor, Smack, Grsec, some more specific things like Trusted Solaris
Also consider that sometimes other forms of isolation, such as OS containers, are implicitly also access control.
Discretionary versus mandatory: (and some variations)
- DAC: discretionary access control
- discretionary: access to an object is at the discretion of the object's owning user
- (...or more precisely the identity of subjects. Usually that's owner-based, though e.g. capability systems often allow transfer to other parts)
- e.g. most filesystem permissions.
- MAC: mandatory access control
- mandatory: the system, not the users, decides access between objects
- often assisted by some sort of sorting objects into categories
- rules decide what labels can interact, and how
- objects are labeled, mostly to keep those rules sane
- often tagged via the filesystem (in a way only the admin can change), because that's practical
- RBAC: role-based access control
- refers not to a way of implementing (like DAC and MAC), but to the abstractions that focus on roles and inheritance and such
- could be used as the basis to implement DAC as well as MAC
And yes, if you squint, there is sometimes very little difference between a category that a MAC system works on and a group that a DAC works on. The difference lies largely in who may change them - the admin, or the relevant user.
This is also roughly why there is value in mixing them. E.g. stricly separate web server, database, and other in terms of many resources. And have users as a third general pile, they can figure out among themselves and mostly just care about filesystem DAC anyway.
It seems that
- SELinux is RBAC-style MAC (for files on top of the existing DAC system)
- AppArmor is DAC & MAC
SELinux is aimed at doing least-privilege via a kernel-enforced rule-based system (MAC)
It's useful in that
- allows protecting/isolating more - think processes, networking, devices. Not just opening files
- even just for files, sometimes what you have in your head is easier to express in rules than purely in classical *nix user/group membership/permissions.
- MAC means there are no complex-to-grasp implications to changing ownership
- (classical DAC-style permissions say only the owner can say what's allowed)
Sometimes adding just one or two MAC style rules let you say "but regardless of owner, thing X should never run" is useful.
- you can whitelist all that is required for predefined tasks
- it makes sense on single/few-purpose servers, much less so on anything workstations
- the last two points may make it easier to have an overview of how secure a system is.
When SELinux is not necessary, it is often both overkill, and typically annoyingly in your way.
- It also takes some serious investment to both understand how to use it, and know how to solve a problem
- ...and to check that it actually solves it
SELinux can be confusing, mostly because it is rarely well-introduced. That said, once understood and applied elegantly, it works well.
Basically a separate log of
- SELinux denials
- system logins
- Account modifications (think useradd, passwd, etc)
- sudo and other authentication events
Since the latter three are typically already there, auditd is mostly a SELinux thing.
Logs are in in /var/log/audit/ by default. auditd chmods the directly containing directory o-rwx, probably because these logs are security-sensitive -- which has bitten me before when (instead of /var/log/audit/audit.log) it was set to /var/log/audit.log - that broke other services trying to acces /var/log.