Defense Against the Dark Arts

Defense Against the Dark Arts

Roman Yaryzhenko — finished paranoid. In case of security holes, he will suspect everyone. Including himself.

and in Linux does not need anti-virus software. But does this mean that he is invulnerable? Despite the fact that Linux is even during the 2.2 kernel was (and still is) quite safe system, standard security, which invented back in the 1970s, sometimes not enough. Modern means of illegitimate penetration is so strong that most people in their implementation might not even notice them.

However, protection is also not standing still. Some of them are invisible to the user and, if lucky, the user will not have to even think about them. Some, on the contrary, require not only fine-tune, but even recompiling the kernel.

Next will be described several protection systems, their history and characteristics.

GRSecurity

This protection system — the oldest in existence. Was it written on the basis of a set of patches OpenWall widely known in narrow circles of the Solar Designer. Use of this system requires some knowledge about how to operate tools hackers, so if something is not clear, read the sidebar «Terminology».

GRSecurity includes PaX — protection against buffer overflow and RBAC [Role-Based Access Control] — role-based access control system that allows flexible management of restrictions and apply them even at the root — root. In addition, this protection system has the following features, which must be specified at compile time:

«A ban write to / dev / mem, / dev / kmem and / dev / port (in the case of the latter, is also prohibited and reading). If even disable loadable module support and the preferred I / O system calls through ioperm / iopl, the legal way to introduce malicious code into the kernel will not be possible. But it is also capable of making it impossible to use some legitimate programs.

«» The Empire Strikes Back «- if the defense sees suspicious activity, instead of completing a process it either initiates a kernel panic [kernel panic] (if the process is running as root) or terminates all processes user account used to run this process and prohibits the establishment of new processes with the UID. «Restricting access to directories / proc / lt; PIDgt ;. When you enable this feature all the programs (except for the running of the explicitly specified user / group) will only see the processes of the user on whose behalf they work.

«Additional restrictions chroot. These include, for example, the prohibition mount inside chroot, ban dual chroot, mknod ban it … With the advent of Linux-containers (LXC) relevant subtree chroot sub-question is put.

»TPE [Trusted Path Execution] — permission to run applications only if the owner of the directory — root, and only he has the right to record.

»TCP / UDP blackhole — the prohibition of sending a package RST / ICMP, if no one listens to the port. Frankly, it is not clear how does this differ from the -J DROP in iptables.

Vocabulary

«Buffer overflow / stack earlier — the most common vulnerability; It based on the fact that some programs and functions enough tightly control their memory, and an attacker may be able to add machine instructions. Modern systems and compilers prevent such attacks; but cracks are not born yesterday and are constantly improving methods of attack.

«Exploit the means by which an attacker carries out the attack, taking advantage of a vulnerability. We exploit a buffer overflow, as a rule, there is, figuratively speaking, «gun» — a program that enables the launch of «bullet» — shell-code.

»ASLR [Address Space Layout Randomization] One means of protection; it randomly carries all the important structures in different locations, making it difficult to hack.

»MAC [Mandatory Access Control] Mandatory Access Control, access control, where the objects (files, devices) are labeled, and the subjects (processes, users) are issued permits. MAC feature is that the subject is unable to fully control the access to your files — this is determined by the selected security policy.

»LSM [Linux Security Modules] feature set and interceptions [hooks] in the kernel Linux, which allows developers to write their own protection system.

«Restrictions sockets for clearly specified group — in this case, you can limit both client and server sockets. »ASLR — randomizes kernel stacks, and user base addresses returned by mmap ().

It must, however, take into account that the protection system is designed, in general, for use on the server — to use it, of course, can be at home, but have a long tune.

To install it, you want to apply a patch to the kernel. At the time of writing, for the imposition of the latest stable version of the patch was necessary to have the kernel source 2.3.50 («vanilla» or base, ie without superimposed party patches). In fact, if there is a need for such a system of protection, it will be much better to use a distribution for which it is native. In the case of such a GRSecurity Hardened Gentoo. But if you still want a headache — they have us. In the sidebar «Compiling GRSecurity» You can find a short step by step description of how to compile under Ubuntu 12.04.

SELinux

SELinux was developed mostly in the NSA [National Security Agency] — US National Security Agency. The first known version of the then unofficial patch has been implemented for the kernel 2.2.19. At the heart of it lay (yes, indeed, to this day there is) security model Flask, designed for research OS Fluke. Creating SELinux also prompted the appearance of LSM — Linus did not want in the nucleus was only SELinux. There he is now in almost every distribution (as in the core is enabled by default), but not everywhere is his policy.

Architecture Flask, on which is built SELinux, realizes the idea of ​​Type Enforcement (TE, sometimes translated as «compulsory assignment types»). It consists in the fact that each object or subject forcibly assigned a security context, which generally consists of four elements and looks like (the elements are separated by colons): unconfined_u: object_r: user_home_t: s0

We will understand what it all means.

«The first element — the user SELinux (not to be confused with the ordinary user), which is defined in the policies. Each SELinux user can be mapped to a standard user. «Next item — the role, as defined in the policy. Each SELinux user can be mapped to one or more roles, one of which will be the main, and the rest — the subsidiary.

«The third element — the type. This is a basic element in the security context, which is used more often. Again, some in politics, he asks what the application can do at all, by specifying certain operations. «Finally, the last item refers to MLS [Multi Level Security, multilevel security] and indicates the degree of confidentiality of the object / subject of the level of tolerance (eg,» secret «,» top secret «…). As a rule, it uses Xia only in specialized policies.

But what do these policies? A policy is precisely describe all valid transactions and in general almost everything related to SELinux: access to files, user SELinux, role transitions types, types of files created …

The distribution Fedora (which, as you know, uses the default SELinux), includes three policies: minimum [minimum], targeted [target] and mls [MLS]. We are interested in the last two.

The targeted policy usually defines quite a few different types. Why not all? Good heavens! Modern operating systems are so complex that the full cooperation of all the components is impossible to describe. Therefore it is better to focus on potentially vulnerable points.

MLS policy is designed for those who need to restrict access to important documents. It is based on a model-LaPaduly Bell [Bell-LaPadula model]. That is — a subject that has access only to the data marked «Confidential» has no right to read the information marked «Top Secret» (this is usually called "No Read Up"), And the subject has access to top secret information, are not allowed to write in secret ("No Write Down"). This policy, as far as we know, is in experimental status, so that it applied to domestic systems, makes no sense.

Looking at the policy files, you will see only the binary data. Policies are available to end users in the compiled form; If you need to change them, you have to put the packets with their source codes. Developers do not have to reinvent the wheel — to compile policies used makrosny preprocessor m4.

The main drawback of SELinux — the complexity of writing policies (need to consider a lot of factors), and the advantage — its flexibility, not to mention the fact that there is already a lot of someone written policies.

AppArmor

AppArmor, nee SubDomain, was designed according to some sources, probably the first GRSecurity. Initially, according to the same sources, it was conceived as a thesis, but later grew into a commercial project. For a while he was a member (and with StackGuard FormatGuard) in the distribution Immunix, which then ceased to exist — the guys from his team decided to focus on supporting SubDomain in SuSE. Then it was bought by Novell and renamed AppArmor. And since kernel 2.6.36, it was included in the mainline kernel.

AppArmor, like other similar systems, is a layer in the kernel. For each application, write your profile, which is a description of what is allowed to make this application. It will be an abridged example of a hypothetical profile for the program foo with the comments — for the reason that AppArmor is easiest to consider the following example.

# Includes file global variable definitions #includelt; tunables / globalgt;

Example # define a variable @ {HOME} = / home / * / / root /

# Path to the application file / usr / bin / foo {

# Turn on auxiliary file — in the future it will simplify the profile greatly, since it listed directives, most of which are valid for all applications

#include lt; abstractions / basegt;

# Specify the types of network connections are available for applications network inet tcp,

# Specify a list of capabilities capability setgid,

# The list of files that the application has access to / bin / mount ux,

/ etc / foo / * r, ib / ld — *. so * mr, lt; / pgt;

/lib/lib*.so* mr, lt; / pgt;

/ proc / [0-9] ** r, lt; / pgt;

/ usr / lib / ** mr, lt; / pgt;

/ tmp / r, owner / shared / foo / ** rw,

# lt; … gt;

# If an application launch foo foobar, it will be applied to the local profile, described below

/ usr / bin / foobar cx,

# In the case of launching any application from the directory / bin / profile will be applied bin_generic

/ bin / ** px -gt; bin_generic

# Local profile foobar foobar {lt; / pgt;

/ bin / bash rmix, / bin / cat rmix, / bin / more rmix, / var / log / foobar * rwl, / etc / foobar r,

}

}

It is necessary to give some explanations about the rules of access.

»R — read, the application can read the file. »W — write, the application can write to it. »A — append, the application can add data to the file. Unlike w lies in the fact that it can not delete data from it, or in any other way to change it; this implies its incompatibility with w. »L — link, the application can use to create hard links.

»K — lock, the application can lock a file.

Separately should also describe the modes of execution (most of them are mutually exclusive):

»Ux — executable application run outside the protection of AppArmor. This mode is not recommended for use as a potentially vulnerable application can be attacker exploit.

»Px — start in the corresponding separate profile.

»Cx — the launch of a local profile; profile should be described in the same file.

»Ix — profile inherited from the parent application.

»M — allows the file to be mapped into memory with a flag PROT_EXEC, which cancels the NX-bit virtual memory pages. In some cases, necessary for libraries. It can be applied to any other mode.

In addition, if the front of the file name put the word owner, the modes of access / execution will be applied only in case of compliance of the file owner and process.

AppArmor allows you to do pretty quickly concoct rules. But there is another side to the coin. There are some potential ways to bypass that because permissions are not stored in the extended attributes, as described in the text file, an attacker could in theory circumvent the protection by using symbolic links. In addition, not all kinds of resources can be put right.

However, for the end user, who does not want to bother with the configuration of protection, AppArmor fit well — its configuration files is very easy to read.

Tomoyo Linux

This system of protection was developed in Japan in 2003 under the auspices of NTT DATA, and at the moment there are two of its branches -1.8 and 2.5. They differ quite significantly. The second branch uses standard functions LSM, which made it possible to include it in the mainline kernel. However, it is also a disadvantage. The branch 1.8 Tomoyo many more features than the one that is included in the official kernel, so here we will describe first.

As AppArmor, Tomoyo does not use the extended attributes of the file system — all files accessed by the application should be spelled out in the policy file. In addition, for each application may be applied a set of parameters called a «profile.» It allows you to specify which security settings should be monitored.

Is possible to use the following restrictions (other than MAC):

«Control sent the application arguments

«Controlling Environment Variables

«Providing verification Capabilities

«The control of network ports and addresses

«Control signals

«Limiting pivot_root and chroot

«Freezing process in the case of non-compliance of its rules of conduct

One feature of Tomoyo — start the process of history. This allows you to limit the scope of the policy.

Example: lt; kernelgt; / usr / sbin / sshd / bin / bash

This line means that if the shell process running sshd, then it applied such a rule; for all other processes of the shell this set of rules is not applicable, which opens up considerable configuration flexibility.

There is also a conditional statements — though the test conditions are not very many. For example, the following lines indicate that the process / bin / dd, running out of Bash, are allowed to read the block devices if uid is 0:

lt; kernelgt; / bin / bash / bin / dd file read / dev / * pathl.type = block task.uid = 0

In addition, to facilitate the creation of policies in Tomoyo has the opportunity to study. That is, when the program starts it should «get rid» of the typical tasks and already on the basis of log files to shape the rules.

Unfortunately, for the normal operation of the branches is necessary to impose a 1.8 patch to the kernel. If you want to see what Tomoyo represents, on the official website of the project (http://tomoyo.sourceforge.jp/index.html.en) have a LiveCD-distributions from Compile in support Tomoyo: one of them — CentOS 6.2, and the other — Ubuntu 12.04.

Conclusion

We have reviewed the most popular solutions for protection against hacking. Which ones are used — depending on the intended conditions of use. Let’s say, for the house in such decisions, provided regular updates to the distribution, there is absolutely no need — but if there was a desire any one to use the most reasonable, in our view, it is the choice of AppArmor.

As for the corporate sector, here again, it all depends on range of tasks. If you really have something to lose and / or business is quite specific, the highest level of security available complex GRSecurity + SELinux. However, it should be borne in mind that security should be provided by a complex of measures, and protection should not be single — in any case we must not forget the human factor.

Finally. Renew often!

Like this post? Please share to your friends: