* [refpolicy] How to handle glibc-triggered behavior? @ 2014-12-21 12:15 Sven Vermeulen 2015-01-12 14:03 ` Christopher J. PeBenito 2015-12-10 14:59 ` Laurent Bigonville 0 siblings, 2 replies; 16+ messages in thread From: Sven Vermeulen @ 2014-12-21 12:15 UTC (permalink / raw) To: refpolicy glibc's malloc implementation, in multithreaded applications, might read /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not (when the allocated memory is part of the non-main arena). That means that read access to sysctl_vm_t becomes a wide request. Not granting privileges might result in different memory behavior, where the system administrator might have tuned/tweaked memory allocations on Linux, but malloc() ignoring this due to SELinux denying access to the settings. I'm wondering how to properly tackle this. Granting this on a per-domain level is probably not manageable, but granting this for all domains (through the "domain" attribute) might be overshooting. Are there specific risks that I should take into account when granting read access to sysctl_vm_t? Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2014-12-21 12:15 [refpolicy] How to handle glibc-triggered behavior? Sven Vermeulen @ 2015-01-12 14:03 ` Christopher J. PeBenito 2015-04-03 13:47 ` Miroslav Grepl 2015-12-10 14:59 ` Laurent Bigonville 1 sibling, 1 reply; 16+ messages in thread From: Christopher J. PeBenito @ 2015-01-12 14:03 UTC (permalink / raw) To: refpolicy On 12/21/2014 7:15 AM, Sven Vermeulen wrote: > glibc's malloc implementation, in multithreaded applications, might read > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > (when the allocated memory is part of the non-main arena). That means that > read access to sysctl_vm_t becomes a wide request. > > Not granting privileges might result in different memory behavior, where the > system administrator might have tuned/tweaked memory allocations on Linux, > but malloc() ignoring this due to SELinux denying access to the settings. > > I'm wondering how to properly tackle this. Granting this on a per-domain > level is probably not manageable, but granting this for all domains (through > the "domain" attribute) might be overshooting. Since typically everything is linked against glibc, and adding read doesn't seem to be very concerning, I'd tend to do the latter. > Are there specific risks that I should take into account when granting read > access to sysctl_vm_t? Looking through the sysctls, I don't really see much to be concerned about. Knowing all the virtual memory settings doesn't seem like it would make any easier to do a denial of service attack. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-01-12 14:03 ` Christopher J. PeBenito @ 2015-04-03 13:47 ` Miroslav Grepl 2015-04-03 15:44 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Miroslav Grepl @ 2015-04-03 13:47 UTC (permalink / raw) To: refpolicy 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. -- Miroslav Grepl Software Engineering, SELinux Solutions Red Hat, Inc. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-04-03 13:47 ` Miroslav Grepl @ 2015-04-03 15:44 ` Dominick Grift 0 siblings, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-04-03 15:44 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2014-12-21 12:15 [refpolicy] How to handle glibc-triggered behavior? Sven Vermeulen 2015-01-12 14:03 ` Christopher J. PeBenito @ 2015-12-10 14:59 ` Laurent Bigonville 2015-12-10 15:11 ` Dominick Grift ` (2 more replies) 1 sibling, 3 replies; 16+ messages in thread From: Laurent Bigonville @ 2015-12-10 14:59 UTC (permalink / raw) To: refpolicy Hey, Le 21/12/14 13:15, Sven Vermeulen a ?crit : > glibc's malloc implementation, in multithreaded applications, might read > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > (when the allocated memory is part of the non-main arena). That means that > read access to sysctl_vm_t becomes a wide request. > > Not granting privileges might result in different memory behavior, where the > system administrator might have tuned/tweaked memory allocations on Linux, > but malloc() ignoring this due to SELinux denying access to the settings. > > I'm wondering how to properly tackle this. Granting this on a per-domain > level is probably not manageable, but granting this for all domains (through > the "domain" attribute) might be overshooting. > > Are there specific risks that I should take into account when granting read > access to sysctl_vm_t? > > Wkr, > Sven Vermeulen I'm bumping this again topic again. Is there anything blocking a fix for this? Cheers, Laurent Bigonville ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 14:59 ` Laurent Bigonville @ 2015-12-10 15:11 ` Dominick Grift 2015-12-10 15:13 ` Dominick Grift 2015-12-10 15:20 ` Dominick Grift 2015-12-10 15:40 ` Dominick Grift 2 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:11 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > Hey, > > Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > glibc's malloc implementation, in multithreaded applications, might read > > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > > (when the allocated memory is part of the non-main arena). That means that > > read access to sysctl_vm_t becomes a wide request. > > > > Not granting privileges might result in different memory behavior, where the > > system administrator might have tuned/tweaked memory allocations on Linux, > > but malloc() ignoring this due to SELinux denying access to the settings. > > > > I'm wondering how to properly tackle this. Granting this on a per-domain > > level is probably not manageable, but granting this for all domains (through > > the "domain" attribute) might be overshooting. > > > > Are there specific risks that I should take into account when granting read > > access to sysctl_vm_t? Is there no sysctl_vm_overcommit_t type for this in refpolicy My concern is with associating this with "domain". I would like to associate as little rules as possible with type attribute for aforementioned reasons. (e.g. domain is mandatory attribute to associate with your process type you do not want to be in a position where you are forced to associate permissions with your type that you do not need) What I would do, and what i do to some degree already in dssp, is i would create various lower level client type attribute for various interpreters and glibs for example. For example: corecmd_shell_client_type will be associated with any process that executes a shell via corecmd_exec_shell() rules like: allow corecmd_shell_client_type self:fifo_file rw_fifo_file_perms; kernel_read_system_state(corecmd_shell_client_type) will be associated. So as soon as you call corecmd_shell_client_type, your process will already have rules common to executing a shell the problem with this approach is the type attribute usage. You cannot associate type attributes with type attributes. Thus: corecmd_exec_shell(myapp_domain) would not work > > > > Wkr, > > Sven Vermeulen > I'm bumping this again topic again. > > Is there anything blocking a fix for this? > > Cheers, > > Laurent Bigonville > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZX+AAoJENAR6kfG5xmcn3kL/j4le20hA7AZKfDW2DPqAOm7 gAAvyAWfDw8UyDxQalfVKu8TvO26msG35QbF3iZQikHpNov4mmnzK/OTRwDcRfL9 LzdvJ8FafxhputhjqfA0Mr+wwOHRwGkKgcDjCtHYVmEKHmwWikHRiP6tCNVnmk8S qZfExk+67qwojPSYn+7CqE/Muh0IcNDQkzmBKvlpqckr6vOfo1dbNQuwgW6+dLPL 7gU6QkNSyksnZkyl0sR4O1YhioBEAJ97nzG1VVVN+T6q/N4GaqqcMeJ8a9NVvCiy avOAlJwrs6XxFg+/28Ep5x2WjNxUxIr623Ya4YEkXNchK/Gdwh0P5seMILHECJm+ ODSiItPCgW+5G2uOMJaLhGy0ybeAouthm9Zfkcg0mYpqSJI82fjPV9bqr8tMvtC6 dJwgI6BqKk8dLWriaYGkbWwRN2YU1tT+SKjZi+taAuQESoCufYzoETvy49rAqeSq yW1CBcBS6VACLrHfFcwg563NLQPsTCWntFu9J824UQ== =xH8q -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:11 ` Dominick Grift @ 2015-12-10 15:13 ` Dominick Grift 2015-12-10 15:44 ` Christopher J. PeBenito 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:13 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 04:10:58PM +0100, Dominick Grift wrote: > On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > > Hey, > > > > Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > > glibc's malloc implementation, in multithreaded applications, might read > > > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > > > (when the allocated memory is part of the non-main arena). That means that > > > read access to sysctl_vm_t becomes a wide request. > > > > > > Not granting privileges might result in different memory behavior, where the > > > system administrator might have tuned/tweaked memory allocations on Linux, > > > but malloc() ignoring this due to SELinux denying access to the settings. > > > > > > I'm wondering how to properly tackle this. Granting this on a per-domain > > > level is probably not manageable, but granting this for all domains (through > > > the "domain" attribute) might be overshooting. > > > > > > Are there specific risks that I should take into account when granting read > > > access to sysctl_vm_t? > > Is there no sysctl_vm_overcommit_t type for this in refpolicy > > My concern is with associating this with "domain". I would like to > associate as little rules as possible with type attribute for > aforementioned reasons. (e.g. domain is mandatory attribute to associate > with your process type you do not want to be in a position where you are > forced to associate permissions with your type that you do not need) > > What I would do, and what i do to some degree already in dssp, is > > i would create various lower level client type attribute for various > interpreters and glibs for example. > > For example: > > corecmd_shell_client_type will be associated with any process that > executes a shell via corecmd_exec_shell() > > rules like: > > allow corecmd_shell_client_type self:fifo_file rw_fifo_file_perms; > kernel_read_system_state(corecmd_shell_client_type) > > will be associated. > > So as soon as you call corecmd_shell_client_type, your process will > already have rules common to executing a shell I meant: So as soon as you call corecmd_exec_shell(), your process will already have rules common to executing a shell > > the problem with this approach is the type attribute usage. You cannot > associate type attributes with type attributes. Thus: > > corecmd_exec_shell(myapp_domain) > > would not work > > > > > > > > Wkr, > > > Sven Vermeulen > > I'm bumping this again topic again. > > > > Is there anything blocking a fix for this? > > > > Cheers, > > > > Laurent Bigonville > > _______________________________________________ > > 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 > https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 > Dominick Grift - -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZZ9AAoJENAR6kfG5xmcunQL/jWPlmQuwrLo5AW9AhyOLRV5 XxxnS4Jc9D5HJ/PWQhJQQdbP2HmEZM0HINOzt5f1D+BPnMVuGt8bqOm5HNzX02op ARz0ttu03Oo1Hh/+HdHJRaYQlUXqmyQCTXcCkXgErbbKS0+pGwedkuo/4ytw0Eyg hvxRnav+ANbCXIUCtIdIzCJ18aLnHoRWKi79ZibkADmTgmGdW9RS7N3BlOcp6lxm 4ZtslGYHf8FjNd/ysTwMngC7rQlamhy+rQ1EmA0zmkVH8G+dGPxw85CXuxfb+nUe PY2h8Ed+IKYBo5JqkIJ5F+lzCLXz7LRByqIKAoicY5IN99VRDWvL+OaFV2mJw2uN Uq5TuHF4icNdoIFBGk1KGtcWGuBXZyzSIR9uGrNnOlka3M1H6/fefX5LO/dJ2v46 YIsAVI2qVlQJwUyXEIqgZdfTe86qmwZDFl5/cBiiyff5XL+E0++vz14mtMChnMUs 3pnfXpZ0JJkvJ2L6kxOtsXBf0rf2+Uhva5VrN8kijQ== =Ea3h -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:13 ` Dominick Grift @ 2015-12-10 15:44 ` Christopher J. PeBenito 2015-12-10 15:49 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Christopher J. PeBenito @ 2015-12-10 15:44 UTC (permalink / raw) To: refpolicy On 12/10/2015 10:13 AM, Dominick Grift wrote: > On Thu, Dec 10, 2015 at 04:10:58PM +0100, Dominick Grift wrote: >> On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville >> wrote: >>> Hey, >>> >>> Le 21/12/14 13:15, Sven Vermeulen a ?crit : >>>> glibc's malloc implementation, in multithreaded applications, >>>> might read /proc/sys/vm/overcommit_memory to check if the >>>> heap can be shrunk or not (when the allocated memory is part >>>> of the non-main arena). That means that read access to >>>> sysctl_vm_t becomes a wide request. >>>> >>>> Not granting privileges might result in different memory >>>> behavior, where the system administrator might have >>>> tuned/tweaked memory allocations on Linux, but malloc() >>>> ignoring this due to SELinux denying access to the settings. >>>> >>>> I'm wondering how to properly tackle this. Granting this on a >>>> per-domain level is probably not manageable, but granting >>>> this for all domains (through the "domain" attribute) might >>>> be overshooting. >>>> >>>> Are there specific risks that I should take into account when >>>> granting read access to sysctl_vm_t? > >> Is there no sysctl_vm_overcommit_t type for this in refpolicy > >> My concern is with associating this with "domain". I would like >> to associate as little rules as possible with type attribute for >> aforementioned reasons. (e.g. domain is mandatory attribute to >> associate with your process type you do not want to be in a >> position where you are forced to associate permissions with your >> type that you do not need) > >> What I would do, and what i do to some degree already in dssp, >> is > >> i would create various lower level client type attribute for >> various interpreters and glibs for example. > >> For example: > >> corecmd_shell_client_type will be associated with any process >> that executes a shell via corecmd_exec_shell() > >> rules like: > >> allow corecmd_shell_client_type self:fifo_file >> rw_fifo_file_perms; >> kernel_read_system_state(corecmd_shell_client_type) > >> will be associated. > >> So as soon as you call corecmd_shell_client_type, your process >> will already have rules common to executing a shell > > I meant: > > So as soon as you call corecmd_exec_shell(), your process will > already have rules common to executing a shell I suspect this is not a good choice. The concept for this access is multithreaded glibc-linked programs. Are there any multithreaded shells? -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:44 ` Christopher J. PeBenito @ 2015-12-10 15:49 ` Dominick Grift 2015-12-10 15:51 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:49 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 10:44:36AM -0500, Christopher J. PeBenito wrote: > On 12/10/2015 10:13 AM, Dominick Grift wrote: > > On Thu, Dec 10, 2015 at 04:10:58PM +0100, Dominick Grift wrote: > >> On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville > >> wrote: > >>> Hey, > >>> > >>> Le 21/12/14 13:15, Sven Vermeulen a ?crit : > >>>> glibc's malloc implementation, in multithreaded applications, > >>>> might read /proc/sys/vm/overcommit_memory to check if the > >>>> heap can be shrunk or not (when the allocated memory is part > >>>> of the non-main arena). That means that read access to > >>>> sysctl_vm_t becomes a wide request. > >>>> > >>>> Not granting privileges might result in different memory > >>>> behavior, where the system administrator might have > >>>> tuned/tweaked memory allocations on Linux, but malloc() > >>>> ignoring this due to SELinux denying access to the settings. > >>>> > >>>> I'm wondering how to properly tackle this. Granting this on a > >>>> per-domain level is probably not manageable, but granting > >>>> this for all domains (through the "domain" attribute) might > >>>> be overshooting. > >>>> > >>>> Are there specific risks that I should take into account when > >>>> granting read access to sysctl_vm_t? > > > >> Is there no sysctl_vm_overcommit_t type for this in refpolicy > > > >> My concern is with associating this with "domain". I would like > >> to associate as little rules as possible with type attribute for > >> aforementioned reasons. (e.g. domain is mandatory attribute to > >> associate with your process type you do not want to be in a > >> position where you are forced to associate permissions with your > >> type that you do not need) > > > >> What I would do, and what i do to some degree already in dssp, > >> is > > > >> i would create various lower level client type attribute for > >> various interpreters and glibs for example. > > > >> For example: > > > >> corecmd_shell_client_type will be associated with any process > >> that executes a shell via corecmd_exec_shell() > > > >> rules like: > > > >> allow corecmd_shell_client_type self:fifo_file > >> rw_fifo_file_perms; > >> kernel_read_system_state(corecmd_shell_client_type) > > > >> will be associated. > > > >> So as soon as you call corecmd_shell_client_type, your process > >> will already have rules common to executing a shell > > > > I meant: > > > > So as soon as you call corecmd_exec_shell(), your process will > > already have rules common to executing a shell > > I suspect this is not a good choice. The concept for this access is > multithreaded glibc-linked programs. Are there any multithreaded shells? I must not have been clear since I believe you misunderstood my point This is not about one this or another. It is about associating common permissions. So proc_vm_overcommit may be common to multithreaded glibc apps, but kernel_read_system_state for example is common to shells. So i am looking to this from the perspective of common rules (for whatever reason they may be common) > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZ7vAAoJENAR6kfG5xmcFv4L/1O7PJiIslAbT9yV8MEwAOn8 atxv4AHvdF5B5H+L0AVjqng11RUJssKMC+MQROUvwFk+CS6GmrGlI7USO+tSCmwl Z3nK+y+3RyGItz3iOgC1JzaJWspRm4uv5bCRO+CsOQVLxGolxBs2yfFDRda2OHD4 Hxeij1IYa4BvLOMy+pOALk4BIsOOXBI4MJEPoigSB/Qt5WVprqm/WVk8doiSeqcb QTl6uS3sENz7f2cIQiI2GOAelxDfeDAL1c+zDHOuPB0QAkCJ1rjasIPKwCfYnDrI +vD/H2zKIa3ODHtKm6z3xHDqkiXdEHz1WW79otm2BreHEnpwkWoMFG2UPwKPmAUZ jNQwg76Rz3MuJl5WuuZWyhi13DmzCiGLZiF5G6fFzVAbEVi953oFw4cYkQDfSd7D k58gDO3mi4mJlB/6Nc6znu4Zj2JakusKdTZrDaMSoEnYGgBlV5tgXFrKn+JRMN9o En8ZENdVVQ7SNeSi0m5EoVVWHEBlHFXekFiHyK/jxA== =BHiO -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:49 ` Dominick Grift @ 2015-12-10 15:51 ` Dominick Grift 0 siblings, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:51 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 04:49:07PM +0100, Dominick Grift wrote: > On Thu, Dec 10, 2015 at 10:44:36AM -0500, Christopher J. PeBenito wrote: > > On 12/10/2015 10:13 AM, Dominick Grift wrote: > > > On Thu, Dec 10, 2015 at 04:10:58PM +0100, Dominick Grift wrote: > > >> On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville > > >> wrote: > > >>> Hey, > > >>> > > >>> Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > >>>> glibc's malloc implementation, in multithreaded applications, > > >>>> might read /proc/sys/vm/overcommit_memory to check if the > > >>>> heap can be shrunk or not (when the allocated memory is part > > >>>> of the non-main arena). That means that read access to > > >>>> sysctl_vm_t becomes a wide request. > > >>>> > > >>>> Not granting privileges might result in different memory > > >>>> behavior, where the system administrator might have > > >>>> tuned/tweaked memory allocations on Linux, but malloc() > > >>>> ignoring this due to SELinux denying access to the settings. > > >>>> > > >>>> I'm wondering how to properly tackle this. Granting this on a > > >>>> per-domain level is probably not manageable, but granting > > >>>> this for all domains (through the "domain" attribute) might > > >>>> be overshooting. > > >>>> > > >>>> Are there specific risks that I should take into account when > > >>>> granting read access to sysctl_vm_t? > > > > > >> Is there no sysctl_vm_overcommit_t type for this in refpolicy > > > > > >> My concern is with associating this with "domain". I would like > > >> to associate as little rules as possible with type attribute for > > >> aforementioned reasons. (e.g. domain is mandatory attribute to > > >> associate with your process type you do not want to be in a > > >> position where you are forced to associate permissions with your > > >> type that you do not need) > > > > > >> What I would do, and what i do to some degree already in dssp, > > >> is > > > > > >> i would create various lower level client type attribute for > > >> various interpreters and glibs for example. > > > > > >> For example: > > > > > >> corecmd_shell_client_type will be associated with any process > > >> that executes a shell via corecmd_exec_shell() > > > > > >> rules like: > > > > > >> allow corecmd_shell_client_type self:fifo_file > > >> rw_fifo_file_perms; > > >> kernel_read_system_state(corecmd_shell_client_type) > > > > > >> will be associated. > > > > > >> So as soon as you call corecmd_shell_client_type, your process > > >> will already have rules common to executing a shell > > > > > > I meant: > > > > > > So as soon as you call corecmd_exec_shell(), your process will > > > already have rules common to executing a shell > > > > I suspect this is not a good choice. The concept for this access is > > multithreaded glibc-linked programs. Are there any multithreaded shells? > > I must not have been clear since I believe you misunderstood my point > > This is not about one this or another. It is about associating common > permissions. s/this/thing > > So proc_vm_overcommit may be common to multithreaded glibc apps, but > kernel_read_system_state for example is common to shells. > > So i am looking to this from the perspective of common rules (for > whatever reason they may be common) > > > > > -- > > Chris PeBenito > > Tresys Technology, LLC > > www.tresys.com | oss.tresys.com > > _______________________________________________ > > 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 > https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 > Dominick Grift - -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZ92AAoJENAR6kfG5xmchQAL/RczosFKhacr222Xj11F2vCj /fLfBQRqiR+J+/FwQvhVJGRqWepzfRKXGFMX3pBpEE85jXufZxORJRdGyfiBd/Qe L1zg3Zdl0nLPzZuDh2WZzQwKIk4wYf3HlNwOPAuU9MamvA8aMqWg19BgFKckVnVJ ULUDME3R55ijamme/73mxefjuuP/osSqBInjcQqHVbS1DkrgQOk1ZXRVFD/V9Pvg H3bu/Sgl9YGEaTHEzTXlB8pWMH9N+Si2GH+VpDcTISAgVne9tT/ToemnjDnpk6K4 DUZ/Fjnb/XlSRm1xsA4OyHOEP/gupMEvZO7s44dTapv6wVnOkgcmVwSo/96ZBPUg h7ZTU0Kc7hOIR/I4HAZQqRi/IKGV8K/O2E7CPR0HV3Ps39uhCxutXrv4kfPjd+2b RdMq/RoBvhj8BWXyX8DDptSIV+9/649w+pO1aqr4ZTKiC89rhHTu7RgSEkeWEIpB jslqUDzTmxDU9Kq+y8JQ7sGOc+XACtL3LHIz5JyPdQ== =QHZE -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 14:59 ` Laurent Bigonville 2015-12-10 15:11 ` Dominick Grift @ 2015-12-10 15:20 ` Dominick Grift 2015-12-10 15:29 ` Dominick Grift 2015-12-10 15:40 ` Dominick Grift 2 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:20 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > Hey, > > Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > glibc's malloc implementation, in multithreaded applications, might read > > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > > (when the allocated memory is part of the non-main arena). That means that > > read access to sysctl_vm_t becomes a wide request. > > > > Not granting privileges might result in different memory behavior, where the > > system administrator might have tuned/tweaked memory allocations on Linux, > > but malloc() ignoring this due to SELinux denying access to the settings. > > > > I'm wondering how to properly tackle this. Granting this on a per-domain > > level is probably not manageable, but granting this for all domains (through > > the "domain" attribute) might be overshooting. > > > > Are there specific risks that I should take into account when granting read > > access to sysctl_vm_t? > > > > Wkr, > > Sven Vermeulen > I'm bumping this again topic again. > > Is there anything blocking a fix for this? I like the idea but i think "domain" should not be used for this. > > Cheers, > > Laurent Bigonville > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZhDAAoJENAR6kfG5xmc1lcL/15emhsOZE9MjSc/gSkt8hKg EnTjV/HuBWQUtMbw94PaiMmcFz1xfQukp1E+caD+cPngCjGVZS674pD43xgZp+5l VaUbvu+V7J2PTyuB2Llm0g1dPOg7AX/53x3Wi8Z8MDTEmxw3QtV1kIfNRGww++XO 7PUc6eavZRDwS0an6jz4PjElbJ3+bJKMA+qj5d7xbORD4rwFY0nnn1JPTEE5n9Ew z2eO7OyP/+PnHpTQyg8OZ7G0xM+hhXy+5FohB95/l9Nv+qxzQSjG66F1PY0oXCJq WQKQZWY1xtEmgRSE4AuMDgm0hB+E7kI2WuXeQK34SqD4X6gCO8JM6PqK+QS1bHuN 1nvIznM5rxfhBvUhQjFyZkbRAurQvHO8/zfcWSoY1mQ/2eqyb4qXS7murD1Fihml sv87xzK+1HyMP95BnjDnHukQeBRgm9vNy8QDvTukA5WzRd53ueJVNgEG3P7qyAl0 ftgRvPKUoWRYqLD9qAWzb0Z8Q7/+Xn2IwDw9XVVDVw== =um/m -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:20 ` Dominick Grift @ 2015-12-10 15:29 ` Dominick Grift 0 siblings, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:29 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 04:20:39PM +0100, Dominick Grift wrote: > On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > > Hey, > > > > Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > > glibc's malloc implementation, in multithreaded applications, might read > > > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > > > (when the allocated memory is part of the non-main arena). That means that > > > read access to sysctl_vm_t becomes a wide request. > > > > > > Not granting privileges might result in different memory behavior, where the > > > system administrator might have tuned/tweaked memory allocations on Linux, > > > but malloc() ignoring this due to SELinux denying access to the settings. > > > > > > I'm wondering how to properly tackle this. Granting this on a per-domain > > > level is probably not manageable, but granting this for all domains (through > > > the "domain" attribute) might be overshooting. > > > > > > Are there specific risks that I should take into account when granting read > > > access to sysctl_vm_t? > > > > > > Wkr, > > > Sven Vermeulen > > I'm bumping this again topic again. > > > > Is there anything blocking a fix for this? > > I like the idea but i think "domain" should not be used for this. I am for creating a common_domain type attribute that inherits "domain", then associate all non-mandatory common permissions with common_domain. This will give people options. I wouldnt use domain for this becuase this sets a precedent. Today it will be this but there are similar requirements imagineable, and similar arguments may be used later to expand this even further. rules common to shells, and a less applicable java for example. Where to draw the line? > > > > > Cheers, > > > > Laurent Bigonville > > _______________________________________________ > > 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 > https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 > Dominick Grift - -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZpCAAoJENAR6kfG5xmc+lkL/RYhAiM9DGQxYIfVKYSgyI9P gP6ax6RFXnfR/WteDhFttPgVl+8fS6NV0j1BkAB1V+cBrt1JI5YY1sUmbh4lYTAr /TJHcmB3tQdw4FVuKfR5+yyGFHrLYbytWN8fATHEqmM+aJ1UVHCiNKWJCfro5oYa 4iC+cY/Rtdw131BOSO4w6k8jAtgF/LhIaRlLT1x8VuuH/Ek+yNfVAtXmbRXK7SZ5 6IaXxFDagA0MFbueyw/pHz35J0yb2IJB6ww1QJYSytYb/R4WRXBWAywzboNiqmUl GnbJoxwSWTFLcBG1Bfi6Q5i3agiaus/P/D4p3poFVviL4tmTQgowoIPIf4F3fbsh LzyVeHH5OxRulP9NCTIJM52ouup01ZuMUm92ouTDYyB0Zh3CHK5jcUClM1rpcm4a vBHZt5XJL8fQEwZIPrKau+8wfNUyKNuxxcgYQHlWxvD1HEvWCCp5S/RzEnV2DmcX UVF7KWWfb5dSksQTu5H7tmhCjZBFwCuJwNxTwde6eA== =wkxu -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 14:59 ` Laurent Bigonville 2015-12-10 15:11 ` Dominick Grift 2015-12-10 15:20 ` Dominick Grift @ 2015-12-10 15:40 ` Dominick Grift 2015-12-10 15:53 ` Christopher J. PeBenito 2 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:40 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > Hey, > > Le 21/12/14 13:15, Sven Vermeulen a ?crit : > > glibc's malloc implementation, in multithreaded applications, might read > > /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > > (when the allocated memory is part of the non-main arena). That means that > > read access to sysctl_vm_t becomes a wide request. > > > > Not granting privileges might result in different memory behavior, where the > > system administrator might have tuned/tweaked memory allocations on Linux, > > but malloc() ignoring this due to SELinux denying access to the settings. > > > > I'm wondering how to properly tackle this. Granting this on a per-domain > > level is probably not manageable, but granting this for all domains (through > > the "domain" attribute) might be overshooting. > > > > Are there specific risks that I should take into account when granting read > > access to sysctl_vm_t? > > > > Wkr, > > Sven Vermeulen > I'm bumping this again topic again. > > Is there anything blocking a fix for this? if we decide to do anything like this then lets start by implementing a proc_vm_overcommit_t type and associate that with /proc/sys/vm/overcommit_memory so that we have more control over this. > > Cheers, > > Laurent Bigonville > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaZzNAAoJENAR6kfG5xmcZVUMAMK1E9/eKK3eOGhvvP5q5SIX xohoA7frNADiwQ2/srwkBERnb29aW9wY7Odg1opz50+abQnqtJcOSV5LXDTFVnc3 PqO/E+MCNzHJ4jqi0tocAz0W0Ih65bd+2qhX4cLSzT+1K2rdX/K9ZjlLQ+fjA5XK sx7iJ3yp9yGuoESz9e4F6nBYjxpNQe0zboTLaxo9XHxXz3dvIn3OB+XjioFDPRRI doZjpMttdQ84z8bqLDq7j8wmujnxuyQp7KxbiFJfML0yFXjKixWhHMmgT+fgAVU4 oKOB3KVT5RGoqQxSJqh4o3OLOVUGTSZSeA05/FBb7pADMvqAteMttwzNIE/GtXNx FJV7FVgC/L8++8Ji8jC1dFvPrU0cw+7qf3jDH4xxzWOyHzL6UqL5kxeeWq9xYlUO Iz+dY+QztOLeWro8BRKFIArWPgOP/9wSqIABo2pj1E78xMTfWrBHOxzLZyQe0rvi pR96zPNHS3X/CiDlAfx6t5LWJsoPvWBJlnGBK4Pqhw== =0PKT -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:40 ` Dominick Grift @ 2015-12-10 15:53 ` Christopher J. PeBenito 2015-12-10 15:56 ` Dominick Grift 2015-12-10 16:00 ` Dominick Grift 0 siblings, 2 replies; 16+ messages in thread From: Christopher J. PeBenito @ 2015-12-10 15:53 UTC (permalink / raw) To: refpolicy On 12/10/2015 10:40 AM, Dominick Grift wrote: > On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: >> Hey, > >> Le 21/12/14 13:15, Sven Vermeulen a ?crit : >>> glibc's malloc implementation, in multithreaded applications, might read >>> /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not >>> (when the allocated memory is part of the non-main arena). That means that >>> read access to sysctl_vm_t becomes a wide request. >>> >>> Not granting privileges might result in different memory behavior, where the >>> system administrator might have tuned/tweaked memory allocations on Linux, >>> but malloc() ignoring this due to SELinux denying access to the settings. >>> >>> I'm wondering how to properly tackle this. Granting this on a per-domain >>> level is probably not manageable, but granting this for all domains (through >>> the "domain" attribute) might be overshooting. >>> >>> Are there specific risks that I should take into account when granting read >>> access to sysctl_vm_t? >>> >> I'm bumping this again topic again. > >> Is there anything blocking a fix for this? > > if we decide to do anything like this then lets start by implementing a > proc_vm_overcommit_t type and associate that with > /proc/sys/vm/overcommit_memory so that we have more control over this. There are a couple things: * Yes, to address this, it would warrant adding a new type for the sysctl, though I'd probably call it sysctl_vm_overcommit_t. * This should trigger some auditing of domains that have access to sysctl_vm_t to see if it is only because of this sysctl, and if so, adjust the access accordingly. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:53 ` Christopher J. PeBenito @ 2015-12-10 15:56 ` Dominick Grift 2015-12-10 16:00 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-12-10 15:56 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 10:53:16AM -0500, Christopher J. PeBenito wrote: > On 12/10/2015 10:40 AM, Dominick Grift wrote: > > On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > >> Hey, > > > >> Le 21/12/14 13:15, Sven Vermeulen a ?crit : > >>> glibc's malloc implementation, in multithreaded applications, might read > >>> /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > >>> (when the allocated memory is part of the non-main arena). That means that > >>> read access to sysctl_vm_t becomes a wide request. > >>> > >>> Not granting privileges might result in different memory behavior, where the > >>> system administrator might have tuned/tweaked memory allocations on Linux, > >>> but malloc() ignoring this due to SELinux denying access to the settings. > >>> > >>> I'm wondering how to properly tackle this. Granting this on a per-domain > >>> level is probably not manageable, but granting this for all domains (through > >>> the "domain" attribute) might be overshooting. > >>> > >>> Are there specific risks that I should take into account when granting read > >>> access to sysctl_vm_t? > >>> > >> I'm bumping this again topic again. > > > >> Is there anything blocking a fix for this? > > > > if we decide to do anything like this then lets start by implementing a > > proc_vm_overcommit_t type and associate that with > > /proc/sys/vm/overcommit_memory so that we have more control over this. > > There are a couple things: > * Yes, to address this, it would warrant adding a new type for the > sysctl, though I'd probably call it sysctl_vm_overcommit_t. Agreed, that was a "typo" on my end > * This should trigger some auditing of domains that have access to > sysctl_vm_t to see if it is only because of this sysctl, and if so, > adjust the access accordingly. > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaaDEAAoJENAR6kfG5xmczSoL/RduwltBoEGjn56v7Jl3Nf4t 3UZayObpVRlRqhAp0HkO57KjWMYEbzlyfeRojF2/z74ikby39z8F1b0Phbjs+Xxr 6tUIReCxmkIIph/ZNkBZmxbyf6eFfwztxIA46r13PdUHQpnl6gs4jJ8cnxMmJlgK O2NkmuXzg0X2gBEgQ80MVuG0y/KCH79kVKVXtHWezAfOSWp5UymFn96j0ag9ltOU E3n7+/rGnRKMidp+f+wcEA52qNBz3FG9OeI0Yx5DBdtgN64DWK52KKCFvJzfcs1C 9fvMy3oxqIGYKD0oCjT58fxUrZKcCd+QnM7Hx3vxYRS5wbXMi8wXXCpiRfJoN6kT cqpYIfUlDgDm5yFmj4/am7UmBtr0Hey58rD4IiACc1ov3jSQcpINWKfJLfmhDznY rhYUI9bMJZ5EjGLKf9mFFvoIMOHrnPeByAfT8dcocLlPaKKbOGbCyR/O3YROk5+D oOGotA1GKs3TfF+4WQbRElcNzLLvmlcqjNoiwZGmhQ== =NN34 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] How to handle glibc-triggered behavior? 2015-12-10 15:53 ` Christopher J. PeBenito 2015-12-10 15:56 ` Dominick Grift @ 2015-12-10 16:00 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-12-10 16:00 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Dec 10, 2015 at 10:53:16AM -0500, Christopher J. PeBenito wrote: > On 12/10/2015 10:40 AM, Dominick Grift wrote: > > On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote: > >> Hey, > > > >> Le 21/12/14 13:15, Sven Vermeulen a ?crit : > >>> glibc's malloc implementation, in multithreaded applications, might read > >>> /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not > >>> (when the allocated memory is part of the non-main arena). That means that > >>> read access to sysctl_vm_t becomes a wide request. > >>> > >>> Not granting privileges might result in different memory behavior, where the > >>> system administrator might have tuned/tweaked memory allocations on Linux, > >>> but malloc() ignoring this due to SELinux denying access to the settings. > >>> > >>> I'm wondering how to properly tackle this. Granting this on a per-domain > >>> level is probably not manageable, but granting this for all domains (through > >>> the "domain" attribute) might be overshooting. > >>> > >>> Are there specific risks that I should take into account when granting read > >>> access to sysctl_vm_t? > >>> > >> I'm bumping this again topic again. > > > >> Is there anything blocking a fix for this? > > > > if we decide to do anything like this then lets start by implementing a > > proc_vm_overcommit_t type and associate that with > > /proc/sys/vm/overcommit_memory so that we have more control over this. > > There are a couple things: > * Yes, to address this, it would warrant adding a new type for the > sysctl, though I'd probably call it sysctl_vm_overcommit_t. > * This should trigger some auditing of domains that have access to > sysctl_vm_t to see if it is only because of this sysctl, and if so, > adjust the access accordingly. I think we can reach a consensus on the above. first things first. Then later we can discuss grouping this further if deemed necessary. Are you going to submit a patch Laurent? > > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > _______________________________________________ > 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 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWaaGQAAoJENAR6kfG5xmcrzML/1kTMpJCiJGPe3Qf18TtOz3g IL8nfHclLCgpzzNlyTB7i+34FmwJiL6i4Qo1xrmod2t2v4wJd0yUJlMBw0C9f1vY I3OFw99CitfnMzZoRixkCw/pvFrcVcrIrIeVZQz4V7KQlMTjHZkhKxk0vfxcx5OC utKL6zSti54dSJluqnFVw6/4Vi7yOmLsA5YGOOdabbkb1/QNW8pw0JRvqu1XY9ED 43wDnRYYPmNUUMUX3d2eRpQhFm9O+uOyiRXtJFwzlVyEIbF0feBNCoI+j6OTQZpb d9Rnevph3osOdF+G0783EsKUBxUs1NaBVhXt4rfxspAGcYPnvMlg35tKiU3urVS0 /L3ZGyqTCW2zEI85iKmQQQfDNhCr/VUzIrcAR00kJgib5C7f3eLee1F7CbHLGgKf 6UW74bbEBilYynGq4YJSikIbJRMzOykTx2omeRvfufsRGP1DFvFuyko9+4XTBI1/ K9dpleI05N3LDRJp4os1D6qh6EAnIBkkDXluL5OIIw== =v7xP -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-12-10 16:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-21 12:15 [refpolicy] How to handle glibc-triggered behavior? Sven Vermeulen 2015-01-12 14:03 ` Christopher J. PeBenito 2015-04-03 13:47 ` Miroslav Grepl 2015-04-03 15:44 ` Dominick Grift 2015-12-10 14:59 ` Laurent Bigonville 2015-12-10 15:11 ` Dominick Grift 2015-12-10 15:13 ` Dominick Grift 2015-12-10 15:44 ` Christopher J. PeBenito 2015-12-10 15:49 ` Dominick Grift 2015-12-10 15:51 ` Dominick Grift 2015-12-10 15:20 ` Dominick Grift 2015-12-10 15:29 ` Dominick Grift 2015-12-10 15:40 ` Dominick Grift 2015-12-10 15:53 ` Christopher J. PeBenito 2015-12-10 15:56 ` Dominick Grift 2015-12-10 16:00 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.