Difference between revisions of "Linux admin notes - security enhanced linux"

From Helpful
Jump to: navigation, search
m (auditd)
m
 
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  (for the filesystem is applied on top of the existing DAC system)
 
* AppArmor is DAC & MAC
 
* AppArmor is DAC & MAC
 
* ...
 
* ...

Latest revision as of 16:54, 6 January 2022

Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts ·· find and xargs and parallel · screen and tmux ·· Shell and process nitty gritty ·· Isolating shell environments


Linux admin - disk and filesystem · Linux networking · Init systems and service management (upstart notes, systemd notes) · users and permissions · Debugging · security enhanced linux · PAM notes · health and statistics · kernel modules · YP notes · unsorted and muck


Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·


Remote desktops



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.

SELinux

SELinux is aimed at being a least privilege style system, via a kernel-enforced rule-based mandatory access control system.


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.




Some description

Status

See also:



auditd

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)

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.


https://www.digrouz.com/mediawiki/index.php?title=(RHEL)_HOWTO_configure_the_auditing_of_the_system_(auditd)