Linux admin notes - security enhanced linux
| Linux-related notes
Shell, admin, and both:
|This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)|
In the access control type view, it seems that
- SELinux is (RBAC-style) MAC (for the filesystem is applied on top of the existing DAC system)
- AppArmor is DAC & MAC
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.
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 file 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.