From: dac.override@gmail.com (Dominick Grift)
Date: Fri, 3 Apr 2015 17:44:53 +0200
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <551E9A08.8080008@redhat.com>
References: <20141221121526.GA5564@siphos.be> <54B3D43A.5060203@tresys.com>
	<551E9A08.8080008@redhat.com>
Message-ID: <20150403154453.GA3192@localhost.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, Apr 03, 2015 at 03:47:52PM +0200, Miroslav Grepl wrote:
> On 01/12/2015 03:03 PM, Christopher J. PeBenito wrote:
> > t seem to be very concerning
> 
> We have
> 
> # /proc/sys/vm/overcommit_memory
> type sysctl_vm_overcommit_t, sysctl_type;
> genfscon proc /sys/vm/overcommit_memory
> gen_context(system_u:object_r:sysctl_vm_overcommit_t,s0)
> 
> and
> 
> kernel_read_vm_overcommit_sysctls(domain)
> 
> for this case in Fedora.

Provided that my sesearch output is accurate (sesearch does not work too well with CIL), i have:

sesearch -ASCT -s subject_type -d
Found 3 semantic av rules:
   allow subject_type rootfs_fs_t : dir { getattr open search } ; 
   allow subject_type systemd_t : process sigchld ; 
   allow subject_type shutdown_t : process sigchld ; 

subject_type is the equivalent of domain, and is a sub-set of:

# sesearch -ASCT -s subject_common_type -d
Found 23 semantic av rules:
   allow subject_common_type sysctl_t : dir { getattr open search } ; 
   allow subject_common_type vm_sysctl_t : dir { getattr open search } ; 
   allow subject_common_type vm_overcommit_sysctl_t : file { ioctl read getattr lock open } ; 
   allow subject_common_type invalid_t : dir { getattr open search } ; 
   allow subject_common_type config_t : dir { getattr open search } ; 
   allow subject_common_type data_t : dir { getattr open search } ; 
   allow subject_common_type devtty_dev_t : chr_file { ioctl read write getattr lock append open } ; 
   allow subject_common_type null_dev_t : chr_file { ioctl read write getattr lock append open } ; 
   allow subject_common_type zero_dev_t : chr_file { ioctl read write getattr lock append open } ; 
   allow subject_common_type exec_t : dir { getattr open search } ; 
   allow subject_common_type exec_t : lnk_file { read getattr } ; 
   allow subject_common_type devtmpfs_fs_t : dir { getattr open search } ; 
   allow subject_common_type proc_fs_t : file { ioctl read getattr lock open } ; 
   allow subject_common_type proc_fs_t : dir { getattr open search } ; 
   allow subject_common_type proc_fs_t : lnk_file { read getattr } ; 
   allow subject_common_type sysfs_fs_t : dir { getattr open search } ; 
   allow subject_common_type securityfs_fs_t : filesystem getattr ; 
   allow subject_common_type libraries_object_type : file { ioctl read getattr execute open } ; 
   allow subject_common_type lib_t : dir { ioctl read getattr lock open search } ; 
   allow subject_common_type lib_t : lnk_file { read getattr } ; 
   allow subject_common_type textrel_shlib_t : file execmod ; 
   allow subject_common_type ld_so_t : file { ioctl read getattr execute open } ; 
   allow subject_common_type ld_so_cache_t : file { ioctl read getattr lock open } ; 

This is what all the processes in my policy are associated with

So in practice it pretty much means that same when it comes to vm_overcommit compared to fedora

The difference with my policy is that i keep a "subject_type" for scenarios where one does not want the rules associated with subject_common_type, however unlikely that may seem

That is basically the only difference, i provide the flexibility for users of my policy to start a policy with really the bare minimum rules without breaking the model

Not because I think any of the rules associated with subject_common_type are dangerous, but just because i acknowledge that i cannot make that decision for users of my policy
and so to stay on the safe side i just built in this caveat

> 
> -- 
> Miroslav Grepl
> Software Engineering, SELinux Solutions
> Red Hat, Inc.
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150403/c9458f6a/attachment.bin