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
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
http://www.tresys.com | oss.tresys.com
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.
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
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
-----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-----
-----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-----
-----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-----
-----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-----
-----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-----
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
http://www.tresys.com | oss.tresys.com
-----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
> http://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-----
-----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
> > http://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-----
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
http://www.tresys.com | oss.tresys.com
-----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
> http://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-----
-----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
> http://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-----