[refpolicy] Support loopback mounts

[refpolicy] Support loopback mounts

[Luis Ressel]

Hello,

currently refpolicy seems not to support loopback mounts (mounts of ordinary
files instead of block devices, for example used by squashfs). There's the type
mount_loopback_t, but the currently granted permissions don't suffice.

The first patch isn't strictly neccessary, however it's useful for my
application scenario, might also be useful for others and doesn't harm security.
The neccessary permissions are added by the second and the third patch.


Regards,
Luis Ressel

[refpolicy] [PATCH 1/3] Allow mount_t to follow mount_loopback_t symlinks

[Luis Ressel]

This is useful for some application scenarios and doesn't harm security.
---
 policy/modules/system/mount.te | 1 +
 1 file changed, 1 insertion(+)

diff --git a/policy/modules/system/mount.te b/policy/modules/system/mount.te
index 03f0911..7d01431 100644
--- a/policy/modules/system/mount.te
+++ b/policy/modules/system/mount.te
@@ -44,6 +44,7 @@ application_domain(unconfined_mount_t, mount_exec_t)
 allow mount_t self:capability { ipc_lock sys_rawio sys_admin dac_override chown sys_tty_config setuid setgid };
 
 allow mount_t mount_loopback_t:file read_file_perms;
+allow mount_t mount_loopback_t:lnk_file read_file_perms;
 
 allow mount_t mount_tmp_t:file manage_file_perms;
 allow mount_t mount_tmp_t:dir manage_dir_perms;
-- 
1.8.5.3

[refpolicy] [PATCH 2/3] Allow mount_t usage of /dev/loop-control

[Luis Ressel]

If loopback devices are not pregenerated (kernel option
CONFIG_BLK_DEV_LOOP_MIN_COUNT=0), mount needs to write to
/dev/loop-control do create them dynamically when needed.
---
 policy/modules/system/mount.te | 1 +
 1 file changed, 1 insertion(+)

diff --git a/policy/modules/system/mount.te b/policy/modules/system/mount.te
index 7d01431..449b3e7 100644
--- a/policy/modules/system/mount.te
+++ b/policy/modules/system/mount.te
@@ -78,6 +78,7 @@ dev_list_all_dev_nodes(mount_t)
 dev_read_sysfs(mount_t)
 dev_dontaudit_write_sysfs_dirs(mount_t)
 dev_rw_lvm_control(mount_t)
+rw_chr_files_pattern(mount_t, device_t, loop_control_device_t)
 dev_dontaudit_getattr_all_chr_files(mount_t)
 dev_dontaudit_getattr_memory_dev(mount_t)
 dev_getattr_sound_dev(mount_t)
-- 
1.8.5.3

[refpolicy] [PATCH 3/3] Grant kernel_t necessary permissions for loopback mounts

[Luis Ressel]

For loopback mounts to work, the kernel requires access permissions to
fd's passed in by mount and to the source files (labeled mount_loopback_t).
---
 policy/modules/kernel/kernel.te | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
index 6a2e170..0742a0c 100644
--- a/policy/modules/kernel/kernel.te
+++ b/policy/modules/kernel/kernel.te
@@ -287,6 +287,10 @@ files_list_etc(kernel_t)
 files_list_home(kernel_t)
 files_read_usr_files(kernel_t)
 
+allow kernel_t mount_t:fd use;
+allow kernel_t mount_loopback_t:fd use;
+allow kernel_t mount_loopback_t:file read_file_perms;
+
 mcs_process_set_categories(kernel_t)
 
 mls_process_read_up(kernel_t)
-- 
1.8.5.3

[refpolicy] [PATCH 2/3] Allow mount_t usage of /dev/loop-control

[Christopher J. PeBenito]

On 1/29/2014 5:45 PM, Luis Ressel wrote:
> If loopback devices are not pregenerated (kernel option
> CONFIG_BLK_DEV_LOOP_MIN_COUNT=0), mount needs to write to
> /dev/loop-control do create them dynamically when needed.
> ---
>  policy/modules/system/mount.te | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/policy/modules/system/mount.te b/policy/modules/system/mount.te
> index 7d01431..449b3e7 100644
> --- a/policy/modules/system/mount.te
> +++ b/policy/modules/system/mount.te
> @@ -78,6 +78,7 @@ dev_list_all_dev_nodes(mount_t)
>  dev_read_sysfs(mount_t)
>  dev_dontaudit_write_sysfs_dirs(mount_t)
>  dev_rw_lvm_control(mount_t)
> +rw_chr_files_pattern(mount_t, device_t, loop_control_device_t)
>  dev_dontaudit_getattr_all_chr_files(mount_t)
>  dev_dontaudit_getattr_memory_dev(mount_t)
>  dev_getattr_sound_dev(mount_t)
 
A proper interface in the devices modules needs to be created to support this access.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/3] Allow mount_t to follow mount_loopback_t symlinks

[Christopher J. PeBenito]

On 1/29/2014 5:45 PM, Luis Ressel wrote:
> This is useful for some application scenarios and doesn't harm security.
> ---
>  policy/modules/system/mount.te | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/policy/modules/system/mount.te b/policy/modules/system/mount.te
> index 03f0911..7d01431 100644
> --- a/policy/modules/system/mount.te
> +++ b/policy/modules/system/mount.te
> @@ -44,6 +44,7 @@ application_domain(unconfined_mount_t, mount_exec_t)
>  allow mount_t self:capability { ipc_lock sys_rawio sys_admin dac_override chown sys_tty_config setuid setgid };
>  
>  allow mount_t mount_loopback_t:file read_file_perms;
> +allow mount_t mount_loopback_t:lnk_file read_file_perms;
>  
>  allow mount_t mount_tmp_t:file manage_file_perms;
>  allow mount_t mount_tmp_t:dir manage_dir_perms;
 
We generally prefer not to specially label symlinks.  They don't have the security properties of the object the point to, and the permissions are checked normally on the target.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 3/3] Grant kernel_t necessary permissions for loopback mounts

[Christopher J. PeBenito]

On 1/29/2014 5:45 PM, Luis Ressel wrote:
> For loopback mounts to work, the kernel requires access permissions to
> fd's passed in by mount and to the source files (labeled mount_loopback_t).
> ---
>  policy/modules/kernel/kernel.te | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
> index 6a2e170..0742a0c 100644
> --- a/policy/modules/kernel/kernel.te
> +++ b/policy/modules/kernel/kernel.te
> @@ -287,6 +287,10 @@ files_list_etc(kernel_t)
>  files_list_home(kernel_t)
>  files_read_usr_files(kernel_t)
>  
> +allow kernel_t mount_t:fd use;

The interface that exists in the mount module should be used for this access.

> +allow kernel_t mount_loopback_t:fd use;

mount_loopback_t is not a process so this has no effect.

> +allow kernel_t mount_loopback_t:file read_file_perms;

An interface needs to be created and used for this access.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH 1/3] Allow mount_t to follow mount_loopback_t symlinks

[Luis Ressel]

On Fri, 31 Jan 2014 22:28:15 -0500
"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:

> We generally prefer not to specially label symlinks.  They don't have
> the security properties of the object the point to, and the
> permissions are checked normally on the target.

My application case is that I'm mounting a regularily updated squashfs
image. The filename of this image includes a timestamp, so I'm using a
symlink; otherwise I'd have to update fstab each time the filename
changes.

I understand that labeling symlinks is uncommon, but in this particular
case it seems like the best solution.

The change clearly doesn't harm security, so I choose to push it
upstream. Perhaps others are also using this scheme, but I'm sure it's
not too common, so I'd also be okay with just applying this patch
locally.


--
Luis Ressel <aranea@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140201/52667ce1/attachment.bin 

[refpolicy] [PATCH 3/3] Grant kernel_t necessary permissions for loopback mounts

[Luis Ressel]

On Fri, 31 Jan 2014 22:32:44 -0500
"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:

> mount_loopback_t is not a process so this has no effect.

When originally developing the policy, this definitively showed up in my
audit log. I removed it now - and it doesn't show up anymore. I don't
know what exactly was going on there.

I'll send an updated patch series.


--
Luis Ressel <aranea@aixah.de>
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140201/4a58d63e/attachment.bin