KVM Security Related: SELinux Svirt

about SELinux (security-enhanced Linux) : (Reference http://blog.csdn.net/flaght/article/details/2973910)

Normal Linux uses the discretionary access control policy (discretionary Acces control, DAC) policy to restrict resource access. This strategy is relatively simple and weak, as long as the required permissions (file owners and file attributes, etc.) can be used resources, which is prone to security risks, and it is difficult to support many security features.

For example, an administrator can allow only one application to add records to a log file but not allow it to overwrite or delete the contents of the log file. Although the ext2 and ext3 file systems have a append-only tag (using the Chattr setting), this property does not differentiate between a process (which is not allowed to be a single access append-only while allowing another process to have a fully writable right); An application can be allowed to create and write data to a folder, but cannot delete the file, which is not available in the DAC, and SELinux comes in handy.

SELinux restricts access to resources based on a mandatory access policy (Mandatory access Control, Mac), and applications must meet both DAC policies and MAC policies to use resources. The DAC takes effect before the Mac, and if the DAC itself does not pass, then the MAC does not participate in the process, and if the DAC passes, SELinux will check it for further access control.

SELinux configuration file is/etc/selinux/config, which manages SELinux packages provided by Libselinux-utils and Policycoreutils

Selinux=permissive|enforcing|disabled

Permissive: warns when a Mac policy violation is found, but does not prevent

Disabled: completely off SELinux

Enforcing: No violation of selinux behavior

Selinuxtype=targeted|mls

Targeted: Target process protection policy

MLS: Multilevel Security Policy

Setenforce

1: Enable SELinux function

0: Turn off SELinux function

Getenforce: Check if the SELinux function is turned on

Sestatus: Gets the status of running SELinux, more detailed than the Getenforce output information

Setsebool: Setting a Boolean value for the configuration item in the SELinux policy

Chcon: Changing the SELinux security context for a file or directory

-T [Type]: Set security context type

-R: Represents a recursive change to the security context of all subdirectories and files

-u [user]: Users who modify the security context

-R [Role]: Modifying the roles of the security context

The security context consists of a user ID, a role, a type of three parts, a user ID provides an identity function, a user can have multiple roles, each role has different permissions, the type is the classification of program principals and resources, and when the type matches, the program can use the resource normally

There are three types of security contexts:

The security context of the account, Id-z view

The security context of the process, ps-z view

Security context for a file or directory, ls-z view

Svirt Introduction :

In a DAC-only policy virtualization environment, because the process running the client runs the same identity, and each client uses the same physical device, it is likely that an attacker could use it to initiate an attack against the host when a client is compromised. Of course, we can also allow each client to use a different running identity to dike this security risk, but this also brings additional problems, when the number of clients, we need to provide many user accounts, in Linux, an account to attach a lot of information (BASHRC, Profile is the recording of this information), which brings a lot of overhead. Therefore, according to the philosophy of compromise, people do not create a different user run process for each client, but draw on this idea, for the client and the resources to play a unique label, only the resources and client tags to match the time to allow its use of resources, The realization of this idea in Linux is Svirt (the combination of SELinux and virtualization).

Svir uses process-based mechanisms and constraints to provide an additional layer of security for clients, and it typically works by using the Libvirt Daemon (LIBVIRTD) in the Rhel system to manage the client behind the back, before starting the client, Libvirt dynamically selects a random MCS tag with two classification flags, such as (S0:C1,C2), to label all storage resources used by the client (SVIRT_IMAGE_T:S0:C1,C2), and then use that tag to start the client. When the client tries to use disk resources and the label is inconsistent, the access is forbidden and an error message is returned.

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/8C/0A/wKioL1hgmUSjqEZUAAKOIvYJDmM290.png "title=" 378{ 7ta56%covds8hhfyiny.png "alt=" Wkiol1hgmusjqezuaakoivyjdmm290.png "/>

Example:

Setenforce 1#svirt is based on SELinux, so to open to cp /bin/bash  /bin/svirt_bash# philosophy of error-proof. Pre-Test Essentials chcon  -t qemu_exec_t /bin/svirt_bash  #指定svirt_bash类型runcon-t svirt_t  -l s0:c1,c2 /bin/svirt_bash   #以svirt_t类型和s0: C1,C2 label Run svirt_bashsvirt_bash: / After the root/.bashrc: permission denied# type is changed, the process does not have permission to read. BASHRC This file does not affect the experiment, but if you do not like the error, you can use: chcon -t   SVIRT_T  -L S0:C1,C2 /ROOT/.BASHRC change the BASHRC tag, so that again run will not error, change before you turn off SELinux, Otherwise prompt no permission to modify, so that after the change is also a problem is to execute other commands will also error, because svirt_t permissions is very small, rather than the default admin_home_tid -z# view the current process label Unconfined_u:unconfined_r: svirt_t:s0:c1,c2svirt_bash-4.1# echo  "It just a test"  > /tmp/1.txtsvirt_ bash-4.1# ls -z /tmp/1.txt  #发现跟svirt_bash   Process-rw-r--r--.  root root  Unconfined_u:object_r:svirt_tmp_t:s0:c1,c2 /tmp/1.txt[[email protected] ~]# runcon -t  svirt_t -l s0:c1,c3 /bin/svirt_bash  #换个标签运行svirt_bash: /root/.bashrc: permission deniedsvirt_bash-4.1# id  -zunconfined_u:unconfined_r:svirt_t:s0:c1,c3svirt_bash-4.1# cat  /tmp/1.txt  #提示没有权限cat:  /tmp/1.txt: permission denied[[email protected] ~]# setenforce 0[[email  protected] ~]# chcon -t svirt_t -l s0:c1,c3 /tmp/1.txt [[email  protected] ~]# setenforce 1[[email protected] ~]# runcon -t  svirt_t -l s0:c1,c3 /bin/svirt_bash svirt_bash: /root/.bashrc: permission  deniedsvirt_bash-4.1# cat  /tmp/1.txt it just a test# Modify 1.txt label re-access, found can, experiment success, note that I changed the parameters when bash is not the same

KVM Security Related: SELinux Svirt