While I think this is a great feature to use, I would not make it mandatory. We have seen this feature impact functionality of certain applications when enabled. Paul M. Whitney E-mail: paul.whitney@mac.com Cell: 410.493.9448 Sent from my browser.
On Jan 19, 2017, at 11:19 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Hi All,
For some time now, I've been adding 'hidepid=2' to my systems to limit process list access to the users that own the processes themselves.
I would like to propose that this be added to the SSG since it provides a very straightforward mechanism for reducing system process enumeration by regular users and/or rogue daemons.
Thanks,
Trevor
While that's a good point, you could say the same thing for a few of the options in here.
IPTables, SELinux, etc...
They *all* say: "do this but turn it off if it doesn't work for you".
In the hidepid case, you can add the gid= option to allow monitoring systems access to the proc table which has worked around all issues that I've seen so far.
If you decide to do this on EL7, be aware that you'll need to start mcstransd (if you're using it) with the group that you specify in the gid= option.
If you have specific cases where the risk of arbitrary user process enumeration outweighs the benefits, I would be most interested to hear them. Fundamentally, this is antithetical to the container approach to the world that is being pushed by so many.
I have seen some issues with poorly written software and have filed bugs with those vendors since they are asking for privileges which they do not require.
Thanks,
Trevor
On Thu, Jan 19, 2017 at 11:58 AM, Paul Whitney paul.whitney@mac.com wrote:
While I think this is a great feature to use, I would not make it mandatory. We have seen this feature impact functionality of certain applications when enabled.
Paul M. Whitney E-mail: paul.whitney@mac.com Cell: 410.493.9448 <(410)%20493-9448> Sent from my browser.
On Jan 19, 2017, at 11:19 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Hi All,
For some time now, I've been adding 'hidepid=2' to my systems to limit process list access to the users that own the processes themselves.
I would like to propose that this be added to the SSG since it provides a very straightforward mechanism for reducing system process enumeration by regular users and/or rogue daemons.
Thanks,
Trevor
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On 1/21/17 4:16 PM, Trevor Vaughan wrote:
While that's a good point, you could say the same thing for a few of the options in here.
IPTables, SELinux, etc...
They *all* say: "do this but turn it off if it doesn't work for you".
In the hidepid case, you can add the gid= option to allow monitoring systems access to the proc table which has worked around all issues that I've seen so far.
If you decide to do this on EL7, be aware that you'll need to start mcstransd (if you're using it) with the group that you specify in the gid= option.
If you have specific cases where the risk of arbitrary user process enumeration outweighs the benefits, I would be most interested to hear them. Fundamentally, this is antithetical to the container approach to the world that is being pushed by so many.
I have seen some issues with poorly written software and have filed bugs with those vendors since they are asking for privileges which they do not require.
Thanks,
We can add it to the catalog, allowing people to enable in tailored profiles. Once systems get socialized it could become enabled by default, akin to how SELinux=1 in RHEL7 content. Mind opening a ticket so we can track this (or, patches welcome :))?
Added at https://github.com/OpenSCAP/scap-security-guide/issues/1648
Unknown time frame for adding a PR but we'll try to if nobody else beats us to it.
On Sun, Jan 22, 2017 at 6:31 PM, Shawn Wells shawn@redhat.com wrote:
On 1/21/17 4:16 PM, Trevor Vaughan wrote:
While that's a good point, you could say the same thing for a few of the options in here.
IPTables, SELinux, etc...
They *all* say: "do this but turn it off if it doesn't work for you".
In the hidepid case, you can add the gid= option to allow monitoring systems access to the proc table which has worked around all issues that I've seen so far.
If you decide to do this on EL7, be aware that you'll need to start mcstransd (if you're using it) with the group that you specify in the gid= option.
If you have specific cases where the risk of arbitrary user process enumeration outweighs the benefits, I would be most interested to hear them. Fundamentally, this is antithetical to the container approach to the world that is being pushed by so many.
I have seen some issues with poorly written software and have filed bugs with those vendors since they are asking for privileges which they do not require.
Thanks,
We can add it to the catalog, allowing people to enable in tailored profiles. Once systems get socialized it could become enabled by default, akin to how SELinux=1 in RHEL7 content. Mind opening a ticket so we can track this (or, patches welcome :))?
https://github.com/OpenSCAP/scap-security-guide/issues/new
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On Sunday, January 22, 2017 6:31:43 PM EST Shawn Wells wrote:
On 1/21/17 4:16 PM, Trevor Vaughan wrote:
While that's a good point, you could say the same thing for a few of the options in here.
IPTables, SELinux, etc...
They *all* say: "do this but turn it off if it doesn't work for you".
In the hidepid case, you can add the gid= option to allow monitoring systems access to the proc table which has worked around all issues that I've seen so far.
If you decide to do this on EL7, be aware that you'll need to start mcstransd (if you're using it) with the group that you specify in the gid= option.
If you have specific cases where the risk of arbitrary user process enumeration outweighs the benefits, I would be most interested to hear them. Fundamentally, this is antithetical to the container approach to the world that is being pushed by so many.
I have seen some issues with poorly written software and have filed bugs with those vendors since they are asking for privileges which they do not require.
Thanks,
We can add it to the catalog, allowing people to enable in tailored profiles
There is a good chance that this breaks existing functionality. Anything that walks the /proc/<pid > listing could have problems, inclusing openscap. I did recommend some sysctls privately that can help with the worst problems in / proc, which is the possibility of working out ASLR addresses. Maybe that is enough for most people?
-Steve
scap-security-guide@lists.fedorahosted.org
-
Paul Whitney -
Shawn Wells -
Steve Grubb -
Trevor Vaughan