Can SELinux policies target a wildcard type?

Support for security such as Firewalls and securing linux
Post Reply
sawozny
Posts: 48
Joined: 2019/07/13 22:19:14

Can SELinux policies target a wildcard type?

Post by sawozny » 2020/05/18 23:35:04

I’m trying to snapshot KVM guests which fails when the system has a second virtual disk that is occupied. I’ve advised RedHat that their virt_qemu_ga_t policy is incomplete here (https://bugzilla.redhat.com/show_bug.cgi?id=1782615 ) but they closed it as a “won’t fix”. I can always run a sudo semanage permissive -a virt_qemu_ga_t but I’m not a fan of disabling SELinux when it’s inconvenient, so I’m trying to write custom policy.

The challenge is that the needed allow rule is to permit source type virt_qemu_ga_t to the label on the mounted directory’s type of class dir for permissions read and ioctl. This is addressable for any individual machine because the off-disk mount point is a folder of just the one type but I want to put this fix into my KVM template and that means the target type for this rule could be anything. This prompts me to inquire if anyone has found a way to set the target type to a wildcard in the AV rule?

As an example, here is the audit2allow -a -t virt_qemu_ga_t -M output for 2 machines with the same problem, but different purposes.

On a web server:

Code: Select all

module qemu_ga_snap_fix 1.0;

require {
	type httpd_sys_content_t;
	type virt_qemu_ga_t;
	class dir { ioctl read };
}

#============= virt_qemu_ga_t ==============
allow virt_qemu_ga_t httpd_sys_content_t:dir { ioctl read };
On a MySQL server:

Code: Select all

module qemu_ga_snap_fix 1.0;

require {
	type mysqld_db_t;
	type virt_qemu_ga_t;
	class dir { ioctl read };
}

#============= virt_qemu_ga_t ==============
allow virt_qemu_ga_t mysqld_db_t:dir { ioctl read };
Removing the differing type line from the require block and replacing the target type in the allow rule with an asterisk like this:

Code: Select all

allow virt_qemu_ga_t *:dir { ioctl read };
returns this error when trying to do a checkmodule:

Code: Select all

checkmodule:  loading policy configuration from qemu_ga_snap_fix.te
qemu_ga_snap_fix.te:10:ERROR '* not allowed in this type of rule' at token ';' on line 10:
allow virt_qemu_ga_t *:dir { ioctl read };
#============= virt_qemu_ga_t ==============
checkmodule:  error(s) encountered while parsing configuration
So this tells me a simple asterisk doesn’t work.

I tried a combined version with this TE file:

Code: Select all

module qemu_ga_snap_fix 1.0;

require {
	type httpd_sys_content_t;
	type mysqld_db_t;
	type virt_qemu_ga_t;
	class dir { ioctl read };
}

#============= virt_qemu_ga_t ==============
allow virt_qemu_ga_t {httpd_sys_content_t mysqld_db_t}:dir { ioctl read };
This file passes checkmodule, packages and installs OK and also allows the snapshot to be created, but this now requires I know all the directory type labels for all off-disk mount points in advance when creating my KVM template OR setting the virt_qemu_ga_t to permissive which isn’t terribly appealing to me from a security perspective.

Has anyone found a way to wildcard the target type for an access vector allow rule?

Any help or suggestions would be appreciated.

Thanks,

Scott

aks
Posts: 3073
Joined: 2014/09/20 11:22:14

Re: Can SELinux policies target a wildcard type?

Post by aks » 2020/05/24 04:51:43

I maybe misunderstanding, but a * for "any directory" seems to be the opposite of what se is there for.

Generally it's a regex, so .* as in:
/bin/.* system_u:object_r:bin_t:s0
/dev/.* system_u:object_r:device_t:s0
/etc/.* system_u:object_r:etc_t:s0
/lib/.* system_u:object_r:lib_t:s0
/opt/.* system_u:object_r:usr_t:s0
/run/.* system_u:object_r:var_run_t:s0

sawozny
Posts: 48
Joined: 2019/07/13 22:19:14

Re: Can SELinux policies target a wildcard type?

Post by sawozny » 2020/05/24 17:28:22

This is for an AVC allow rule which has source and target type, so the goal is to allow the Qemu guest agent to read the properties of directories which are the mount point for a resource not on the system disk WITHOUT knowing in advance what type that directory is labeled with. The directory names are of no relevance in this context (pun partially intended).

Post Reply