Howevever, an empirical approach is possible. Once the relevant objects are correctly labelled, you can use the application in permissive mode: the operations that would be forbidden are logged but still succeed. By analysing the logs, you can now identify the operations to allow. Here is an example of such a log entry:
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file
To better understand this message, let us study it piece by piece.
Table 14.1. Analysis of an SELinux trace
Message
Description
avc: denied
An operation has been denied.
{ read write }
This operation required the
read
and
write
permisions.
pid=1876
The process with PID 1876 executed the operation (or tried to execute it).
comm="syslogd"
The process was an instance of the
syslogd
program.
name="xconsole"
The target object was named
xconsole
.
dev=tmpfs
The device hosting the target object is a
tmpfs
(an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example: “hda3”).
ino=5510
The object is identified by the inode number 5510.
scontext=system_u:system_r:syslogd_t:s0
This is the security context of the process who executed the operation.
tcontext=system_u:object_r:device_t:s0
This is the security context of the target object.
tclass=fifo_file
The target object is a FIFO file.
By observing this log entry, it is possible to build a rule that would allow this operation. For example: allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it's exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labelled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.
COMPLEMENTS No roles in policy rules
It might seem weird that roles do not appear at all when creating new rules. SELinux uses only the domains to find out which operations are allowed. The role intervenes only indirectly by allowing the user to switch to another domain. SELinux is based on a theory known as Type Enforcement and the type is the only element that matters when granting rights.
14.4.4.4. Compiling the Files
Once the 3 files (example.if, example.fc, and example.te) match your expectations for the new rules, just run make to generate a module in the example.pp file (you can immediately load it with semodule -i example.pp). If several modules are defined, make will create all the corresponding .pp files.
14.5. Other Security-Related Considerations
Security is not just a technical problem; more than anything, it's about good practices and understanding the risks. This section reviews some of the more common risks, as well as a few best practices which should, depending on the case, increase security or lessen the impact of a successful attack.
14.5.1. Inherent Risks of Web Applications
The universal character of web applications led to their proliferation. Several are often run in paralleclass="underline" a webmail, a wiki, some groupware system, forums, a photo gallery, a blog, and so on. Many of those applications rely on the “LAMP” (Linux, Apache, MySQL, PHP) stack. Unfortunately, many of those applications were also written without much consideration for security problems. Data coming from outside is, too often, used with little or no validation. Providing specially-crafted values can be used to subvert a call to a command so that another one is executed instead. Many of the most obvious problems have been fixed as time has passed, but new security problems pop up regularly.
VOCABULARY SQL injection
When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible.
→ http://en.wikipedia.org/wiki/SQL_Injection
Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a script kiddy) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.
14.5.2. Knowing What To Expect
A vulnerability in a web application is often used as a starting point for cracking attempts. What follows is a short review of possible consequences.
QUICK LOOK Filtering HTTP queries
Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.
Setting up these checks can be a long and cumbersome task, but it can pay off when the web application to be deployed has a dubious track record where security is concerned.
mod-security (in the libapache-mod-security package) is the main such module.
The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. Script-kiddies only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines.
A more advanced attacker will go beyond that. A disaster scenario could go on in the following fashion: the attacker gains the ability to execute commands as the www-data user, but executing a command requires many manipulations. To make their life easier, they install other web applications specially designed to remotely execute many kinds of commands, such as browsing the filesystem, examining permissions, uploading or downloading files, executing commands, and even provide a network shell. Often, the vulnerability will allow running a wget command that will download some malware into /tmp/, then executing it. The malware is often downloaded from a foreign website that was previously compromised, in order to cover tracks and make it harder to follow the scent to the actual origin of the attack.
At this point, the attacker has enough freedom of movement that they often install an IRC bot (a robot that connects to an IRC server and can be controlled by this channel). This bot is often used to share illegal files (unauthorized copies of movies or software, and so on). A determined attacker may want to go even further. The www-data account does not allow full access to the machine, and the attacker will try to obtain administrator privileges. Now, this should not be possible, but if the web application was not up-to-date, chances are that the kernel and other programs are outdated too; this sometimes follows a decision from the administrator who, despite knowing about the vulnerability, neglected to upgrade the system since there are no local users. The attacker can then take advantage of this second vulnerability to get root access.