All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0
I have generally set this to:
* - core 0
Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Regards,
Frank Caviggia
On 9/30/13 11:28 AM, fcaviggi@redhat.com wrote:
All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0I have generally set this to:
* - core 0Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Good call. Make a patch.
I'm up for both.
On Mon, Sep 30, 2013 at 11:41 AM, Shawn Wells shawn@redhat.com wrote:
On 9/30/13 11:28 AM, fcaviggi@redhat.com wrote:
All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0I have generally set this to:
* - core 0Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Good call. Make a patch.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
As a note, both:
* - core 0
AND
* hard core 0 * soft core 0
Should pass.
Trevor
On Mon, Sep 30, 2013 at 11:28 AM, fcaviggi@redhat.com wrote:
All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0I have generally set this to:
* - core 0Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Regards,
Frank Caviggia
-- Frank Caviggia Consultant, Public Sectorfcaviggi@redhat.com (M) (571) 295-4560
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Sorry for the double post. I just wanted to make sure that the presence of the 'soft' line didn't throw an error.
On Sat, Oct 5, 2013 at 9:35 PM, Trevor Vaughan tvaughan@onyxpoint.comwrote:
As a note, both:
- core 0
AND
- hard core 0
- soft core 0
Should pass.
Trevor
On Mon, Sep 30, 2013 at 11:28 AM, fcaviggi@redhat.com wrote:
All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0I have generally set this to:
* - core 0Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions *) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Regards,
Frank Caviggia
-- Frank Caviggia Consultant, Public Sectorfcaviggi@redhat.com (M) (571) 295-4560
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Trevor,
The hard and '-' (which sets both hard and soft) are the primary controls, 'soft' is overruled by the 'hard' setting.
That's why those are the most important to check.
Regards,
Frank
On 10/05/2013 09:35 PM, Trevor Vaughan wrote:
Sorry for the double post. I just wanted to make sure that the presence of the 'soft' line didn't throw an error.
On Sat, Oct 5, 2013 at 9:35 PM, Trevor Vaughan <tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com> wrote:
As a note, both: * - core 0 AND * hard core 0 * soft core 0 Should pass. Trevor On Mon, Sep 30, 2013 at 11:28 AM, <fcaviggi@redhat.com <mailto:fcaviggi@redhat.com>> wrote: All, Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf: * hard core 0 I have generally set this to: * - core 0 Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value. I'd also to fix the maxlogins in the rule (*max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value? Regards, Frank Caviggia -- Frank Caviggia Consultant, Public Sector fcaviggi@redhat.com <mailto:fcaviggi@redhat.com> (M)(571) 295-4560 <tel:%28571%29%20295-4560> _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 <tel:%28410%29%20541-6699> tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> -- This account not approved for unencrypted proprietary information ---- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
I just found the relevant code and have no worries.
Thanks for the response!
Trevor
On Sat, Oct 5, 2013 at 11:25 PM, fcaviggi@redhat.com wrote:
Trevor,
The hard and '-' (which sets both hard and soft) are the primary controls, 'soft' is overruled by the 'hard' setting.
That's why those are the most important to check.
Regards,
Frank
On 10/05/2013 09:35 PM, Trevor Vaughan wrote:
Sorry for the double post. I just wanted to make sure that the presence of the 'soft' line didn't throw an error.
On Sat, Oct 5, 2013 at 9:35 PM, Trevor Vaughan tvaughan@onyxpoint.comwrote:
As a note, both:
- core 0
AND
- hard core 0
- soft core 0
Should pass.
Trevor
On Mon, Sep 30, 2013 at 11:28 AM, fcaviggi@redhat.com wrote:
All,
Most of the guidance for RHEL security has suggested setting the following in /etc/security/limits.conf:
* hard core 0I have generally set this to:
* - core 0Because this sets both the hard and soft limits on the system. Most SCAP scanners are looking for very specific values there. I'm looking at modifying the checks to pass either 'hard' or '-' for the value.
I'd also to fix the maxlogins in the rule (* max_concurrent_login_sessions*) in /etc/security/limits.conf to look for the DOD default (10) and lower to satisfy the check. Security standards are there as a baseline, why 'fail' the setting for exceeding the baseline value?
Regards,
Frank Caviggia
-- Frank Caviggia Consultant, Public Sectorfcaviggi@redhat.com (M) (571) 295-4560
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- Frank Caviggia Consultant, Public Sectorfcaviggi@redhat.com (M) (571) 295-4560
scap-security-guide@lists.fedorahosted.org
-
Frank Caviggia -
leam hall -
Shawn Wells -
Trevor Vaughan