Rationale behind SELinux preventing file access

Question

Some of the few times I've had to deal with SELinux were when I setup a local webserver on a Fedora box. Problems occurred when a web application tried to write files to the file system.

I'm used to setting up Posix file permissions properly, so one of the first steps I always perform is chown apache:apache -R /var/www/. Subsequently, I only use the apache user to interact with the webroot or the web applications.

However, on Fedora, SELinux prevents writing to files. I followed the SELinux troubleshooter's advice to disable this protection, but it got me wondering.

Why would SELinux prevent file write access for a process (apache) when that process is already running as its own user, and regular old file permissions can thus be setup easily, specific for Apache? And are there any other use cases that make (more) sense for this kind of file access prevention?

Answer 1

TL;DR

Set access levels for individual web applications.

Did read

After reading this page, I think I've got a good idea of the rationale. In SELinux, each file has a security context. You can view the current security context with ls -Z <path>, and set a new security context with chcon.

All web apps will be run as the apache user, so under normal circumstances, each web app will have the same permissions. With security contexts, you can confine the access of individual apps/script. By default, scripts have read-only access.

This is actually quite useful for security. Let's say you have an application you trust, which requires write access. You would explicitly give that script the httpd_unconfined_script_exec_t context. Now let's say you have an insecure application that is prone to exploits. You would leave the security context of the script(s) belonging to that application at the default, which prevents writing files.

Preventing file writes would prevent a whole range of attacks which exploit some vulnerability to write a script to disk, which can subsequently be executed over http by the attacker.

Answer 2

I think part of the answer relates to something you mention:

I'm used to setting up Posix file permissions properly, so one of the first steps I always perform is chown apache:apache -R /var/www/. Subsequently, I only use the apache user to interact with the webroot or the web applications.

Why do you do this?

Most likely to help protect your system from a rogue process, or compromise.

seLinux is another layer/mechanism to help achieve the same.

A sensible (and best practice) approach to security is to layer your defenses, and more generally, to try and use several means of protecting your system. If they overlap, great: the more different ways of protecting the same thing, the more an attacker needs to work to achieve their goals.

The basic idea with seLinux preventing writes (or reads) is that, as with POSIX, you need to explicitly grant the access to a programme which it will require.

/var/www will in a large number of cases legitimately be read-only: static sites would be one obvious case. In your case, you don't mention ever chmod'ing /var/www, so that quite likely, it would be 750 (or 700), and owned by apache.

In that case, seLinux is, at very least, making you think about whether that chmod, and level of access, is in fact needed: unless you do in fact need to write files, it probably isn't, and it seems reasonable to say seLinux is in fact helping avoid functionality/access being available that isn't needed.

You are focusing on the POSIX-like qualities, but seLinux also allows you to prevent apache from initiating outbound connections, for example, and can constrain the outbound connections that are allows to a small number of ports. Personally, I sometimes find it useful to view seLinux's capabilities as being akin to an enforcing auditd daemon - you are looking at behaviour, and can be much more specific about acceptable behaviour, than POSIX makes possible (in part because POSIX is not so much about protection, and more about compatibility and providing a basic, stable set of features).

I might pay to read what Wikipedia has to say about both POSIX and SELinux - and also to consider the fact POSIX provides Discretionary Access Control, where seLinux provides Mandatory Access Control.

The DAC/MAC differences are to a point key to answering your question: MAC is generally a system-wide policy that is centrally controlled (typically with an eye to ensuring a system 'functions correctly'), where DAC allows local decisions to be made - there is an obvious tension between these approaches, and seLinux is there to ensure the global policy is applied even in the face of local decisions that might undermine it.

Answer 3

I can't make sense of this file access restriction, knowing a sysadmin could just do chmod -R -w /var/www/html/

I think the threat here isn't the user trying to access his own files, but the program being exploited.

Imagine Firefox falling victim to a memory corruption attack that enables the attacker to run arbitrary code : if SELinux restricts Firefox's access to the only files it needs to work, it can't do harm elsewhere, like your personal files and the rest of the system.

Also, you talk about a sysadmin, which makes me think that you should define more precisely what you think SELinux defends the system against. The sysadmin has root access by definition and nothing can therefore prevent him from doing anything. SELinux mitigates rogue users and program exploits, but it can't do miracles.