Linux admin notes - security enhanced linux

From Helpful
Jump to: navigation, search
Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts · Shells and execution ·· find and xargs and parallel · screen and tmux
Linux admin - disk and filesystem · users and permissions · Debugging · security enhanced linux · 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
VNC notes
XDMCP notes



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)

Approaches to access control

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)

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.


For context,

  • DAC: discretionary access control
discretionary in that the access to an object is at the discretion of the object's owner
(...or more precisely the identity of subjects. Usually that's owner-based, though e.g. capability systems often allow transfer to other parts)


  • MAC: mandatory access control
the system, not the users, decides access between objects
rules decide what labels can interact, and how
objects are labeled, mostly to keep those rules sane
sort of imitates security agency / military style, and can be modeled off it if you want.
you can sort of implement DAC with MAC as well. Not the sanest choice.


  • RBAC: role-based access control
refers not to a way of implementing (like DAC and MAC), but to the abstractions that focus on roles, inheritance, processes, etc.
could be used as the basis to implement DAC as well as MAC


It seems that

  • SELinux is RBAC & MAC (for files on top of the existing DAC system)
  • AppArmor is a DAC & MAC
  • ...


SELinux

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)


  • SELinux is aimed at doing least-privilege via a kernel-enforced rule-based system (MAC)
...rather than just filesystem permissions (DAC)
Where it is feasible to whitelisting all actions that are required is feasible, it is much more obvious to inspect/infer how secure a system is.
  • Why this approach?
    • it's a separate subsystem because you often want to protect/isolate more than files - think processes, networking, devices.
    • MAC on top of DAC: DAC means only the owner can say what's allowed (and note that change of ownership sometimes has complex-to-grasp implications). Adding MAC means you can have rules on top of that.
note: MAC checks apply after such DAC checks.
  • In some cases it's just easier to put certain filesystem restrictions in the form of rules rather than membership/permissions
  • Only really makes sense to use when whitelisting everything that should be allowed is a manageable task
it makes sense on single/few-purpose servers, much less so on workstations


When SELinux is not necessary, it is often both overkill and typically only 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.

We throw these acronyms about and spend a lot of words, particularly on the RBAC part of it, in a philosophical or technical description of how SELinux works.

That said, once understood and applied elegantly, it works well.




Some description

Status

See also:



auditd

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.


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