Linux admin notes - security enhanced linux: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 6: | Line 6: | ||
In the [[access control type]] view, it seems that | 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) | * SELinux is ([[RBAC]]-style) MAC (note that for the filesystem, is applied on top of the typically-existing DAC system) | ||
* AppArmor is DAC & MAC | * AppArmor is DAC & MAC | ||
* ... | * ... | ||
Other things in the area you may wish to look at: | Other things in the area you may wish to look at: | ||
Line 15: | Line 14: | ||
Also consider that sometimes other forms of isolation, such as OS containers, are implicitly also access control. | Also consider that sometimes other forms of isolation, such as OS containers, are implicitly also access control. | ||
===SELinux=== | ===SELinux=== | ||
SELinux is | SELinux is a kernel-enforced rule-based [[access control type|mandatory access control]] system. | ||
Is often explained and used as a [[least privilege]] style system. | |||
It's useful in that | It's useful in that | ||
* allows protecting | * allows protecting more than just files - think processes, networking, devices | ||
* | * at larger scale, the classical *nix user/group membership/permissions often becomes too hard to model things in. | ||
: SELinux's rule system is usually at the level of expressiveness you'ld like | |||
* MAC | * In MAC, changing file ownership has no complex-to-grasp implications | ||
: (classical DAC-style permissions say ''only'' the ''owner'' can say what's allowed) | : (classical DAC-style permissions say ''only'' the ''owner'' can say what's allowed)<!-- | ||
e.g. 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 | * you can whitelist all that is required for predefined tasks |
Latest revision as of 15:05, 4 February 2024
Linux-related notes
Shell, admin, and both:
|
In the access control type view, it seems that
- SELinux is (RBAC-style) MAC (note that for the filesystem, is applied on top of the typically-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.
SELinux
SELinux is a kernel-enforced rule-based mandatory access control system.
Is often explained and used as a least privilege style system.
It's useful in that
- allows protecting more than just files - think processes, networking, devices
- at larger scale, the classical *nix user/group membership/permissions often becomes too hard to model things in.
- SELinux's rule system is usually at the level of expressiveness you'ld like
- In MAC, changing file ownership has no complex-to-grasp implications
- (classical DAC-style permissions say only the owner can say what's allowed)
- 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.
Some description
Status
See also:
- http://wiki.centos.org/HowTos/SELinux
- http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
- http://www.slideshare.net/PaulWay/selinux-for-everyday-users
- http://selinuxproject.org/page/Main_Page
- http://en.wikipedia.org/wiki/Security-Enhanced_Linux
auditd
Often used as a separate log of
- SELinux denials
- system logins
- Account modifications (think useradd, passwd, etc)
- sudo and other authentication events
auditd is sort of a SELinux thing, in that it centralizes a bunch of things the person configuring SELinux, and those doing security checks, will be interested in.
You can also configure it to monitor
specific file permission changes,
specific types of file operations - potentially all file related syscalls (though would probably not do so under regular operation),
and more.
Logs are in in /var/log/audit/ by default. auditd does a chmods o-rwx to the directory containing its logs, because these logs may be are security-sensitive.
This 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 read /var/log.