Linux kernel forced access control-apparmor

Ubuntu now has its own apparmor and can get the appropriate information in the manual. The article is from a lot of English data collated summed up, there may be inaccurate places, please forgive me.

Access Control with program bindings

The access control provided by AppArmor is bound to the program:

AppArmor ' s unique security model are to bind access control attributes to programs rather than to users.
Suppose you have an executable path of/home/361way/demoexe, and if you want to use AppArmor to access it, create a new configuration file (I'll talk about how to write this profile later). The file name is Home.361way.demoexe and the configuration file is placed in the AppArmor directory where the configuration file is specifically placed (/ETC/APPARMOR.D). So each executable file is bound to a configuration file, so if you modify the Demoexe filename, the profile will fail.

Two modes of operation

AppArmor has two modes of operation: enforcement, Complain/learning

enforcement– in this mode, the restrictions listed in the configuration file are executed, and the programs that violate these restrictions are logged.

complain– in this mode, the constraints in the configuration file are not enforced, and AppArmor simply records the behavior of the program. For example, a program can write a file that is read-only in a configuration file, but AppArmor does not limit the behavior of the program, just record it.

Since complain cannot restrict the program, why does it need this mode, because--if a program's behavior does not conform to its configuration file restrictions, it can log its behavior to the system log, and can be converted to a configuration file based on the behavior of the program.

Of course, we can modify the configuration file at any time, choose the mode we need.

Iii. access control and resource constraints

AppArmor can restrict the program in many ways, I'll just introduce some of the commonly used

(1) Access control of file system

AppArmor can control access to a file, or to a file in a directory, including the following access modes:

Readable, writable, extensible, linked, etc. (and executable x is not listed in the table) ...

The wording in the configuration file, such as

such as/TMP R, (indicates that the files in the/tmp directory can be read)
Note that the files that are not listed in the configuration file, the program is inaccessible, which is a bit like whitelist.

(2) Resource constraints

AppArmor can provide similar system call Setrlimit to restrict the resources that the program can use. To limit resources, you can write this in the configuration file:

Set rlimit [resource] <= [value],
The resource represents a resource, value represents a value, and when you limit the virtual memory that your program can use, you can write this:

Set Rlimit as<=1m (max. 1M of virtual memory available)
Note: AppArmor can restrict programs to use multiple resources (fsize,data,stack,core,rss,as,memlock,msgqueue, etc.), but it does not support the use of CPU time for programs. (now OJ generally have strict restrictions on the running time of Acmer-submitted programs, so to use AppArmor for OJ back-end security modules, you have to implement additional limits on CPU time.) ）

(3) Access to the network

AppArmor can program access to the network for restrictions, the syntax in the configuration file is:

network [[domain] [type] [protocol]]
Understanding network programming should know what domain, type, and protocol are. To allow the program to perform all network operations, simply write in the configuration file:

Network,
To allow a program to use the TCP protocol under IPV4, you can write this:

Network inet TCP,
(4) Capability entry

In the Linux hand album there is a capablities list, AppArmor can restrict whether the program can be listed in the operation, such as: Capability Setgid, (allow the program to do setgid operation)

Capability statements are simply the word Capability followed by the name of the POSIX.
1e Capability as defined in the capabilities (7) Mans page.
Digression: These features, there is no thought of/proc/pid/under the file, there are Python resource modules related to things, but AppArmor management more concise and flexible.

Iv. Preparation of configuration documents

As mentioned earlier, when you finish writing the configuration file, put the file in the/ETC/APPARMOR.D directory, there is a more convenient way, directly in the command line with:

sudo genprof [filename]
You can create a configuration file for the specified program and place it in the directory. Such as:

sudo genprof '/home/361way/apparmor-helper/demoexe '
The configuration file is set up as follows:

#include <tunables/global>
/home/361way/apparmor-helper/demoexe {
#include <abstractions/base>
}
Note that the file defaults to enforcement mode, and to modify the mode, simply change the configuration file to:

#include <tunables/global>
/home/361way/apparmor-helper/demoexe flags= (complain) {
#include <abstractions/base>
}
The previous section of flags= (complain) is the path to the file, which is to bind a program to the configuration file. Then you can add the appropriate content to the configuration file, plus the braces:

/home/361way/apparmor-helper/data RW,
Set Rlimit stack<=1m,
And then execute the command:

Sudo/etc/init.d/apparmor Reload
You can reload the configuration file so that the configuration file takes effect.

Summary and Expansion:

In the DOCKER/LXC documentation, you'll find apparmor related parts, such as online judge these applications are also linked to Apparmor/selinux. Mention the above to have to mention the Sandbox (sandbox), the sandbox is not only useful for security, but also in many cases to replace the virtual machine based application isolation scheme (sandbox process is the most efficient virtual machine), and Linux sandbox application is based on apparmor/ SELinux's.