Linux admin notes - security mechanisms in linux

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 ·· Shell flow control notes 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 · Machine Check Events · kernel modules · YP notes · unsorted and muck · Automounters and permissions Logging and graphing - Logging · RRDtool and munin notes Network admin - Firewalling and other packet stuff · Remote desktops

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Anyone has DAC

Linux by itself has file permissions, ACLs, chroot jails, firewalling, and such - which fall under discretionary access control.

SELinux adds mandatory access control. To oversimplify: MAC is a more detailed model of things that interact (processes, files, sockets, network interfaces, etc.), so you can restrict things in more specific and often more meaningful than what you can do with basic linux.

MAC is more bottom-up; where DAC often means a assuming a single process is trusted to play nice, MAC is a system of least-privilege: assume no interaction is allowed until a policy specifically allows it.

Adding MAC / RBAC to linux

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.

SELinux 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

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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)

Capabilities

Kernel capabilities are an implementation of POSIX capability-based security (see 1003.1e).

This means that instead of "you are now root and can do everything" (usually via sudo or SUID root) you now have something much more fine-grained.

Basically, it means you can actually do some least privilege damming in of what ill intent and/or bugs may imply.

Capabilities roughly means they've organized syscalls into a bunch of groups, and allow granting per these groups.

Consider e.g. ping.

Historically this was SUID root, which it needed to create a raw socket.

Yes, it drops it as soon as it doesn't need it anymore, and in many practical ways this is pretty safe, but there is a period where it is entirely privileged.

In the case of ping, the OS's package manager installed it, and you can trust them to have done some security checks. This is less true of more custom software, though. My ping is better, just use this sudo command, it's fiiiine.

Capabilities allow you to give ping CAP_NET_RAW (and maybe CAP_NET_ADMIN?), and none of the other capabilities.

Such capabilities can also be used in a SUID-like way, by using xattr to assign them.

Note that ping itself doesn't care how it gets these things. In fact it doesn't even know, beyond the relevant syscalls (not) failing.

http://man7.org/linux/man-pages/man7/capabilities.7.html