[PATCH] /etc/login.defs password rules - allow heading spaces, trailing comments. Start using shared version for maximum password age
by Jan Lieskovsky
Patch summary:
[shared] Modify /etc/login.defs rules to allow heading spaces & trailing comments
[shared] Move accounts_maximum_age_login_defs.xml to shared
[shared] Add Fedora 20 as another platform identifier for password /etc/login.defs rules
[shared] Update test attestations timestamps for RHEL & Fedora (for password /etc/login.defs rules)
[Fedora] Replace own copies of /etc/login.defs password OVAL checks with the shared ones
[RHEL/6] Make a link for accounts_maximum_age_login_defs.xml from shared
[RHEL/7] Make a link for accounts_maximum_age_login_defs.xml from shared
Testing report:
The proposal has been tested on all of RHEL-6, RHEL-7, and Rawhide for both
combinations (with / without trailing comments, with / without heading spaces)
and seems to be working properly in all cases (further review / testing appreciated
of course).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years
[PATCH] [shared] Allow comments in sshd config directives
by Jan Lieskovsky
When checking /etc/ssh/sshd_config for proper settings of various
directives allow also line directive versions suffixed with comments
(so we wouldn't report inappropriate results).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years
[RFC] time to move to github?
by Shawn Wells
As the SSG development community grows, so does the need for matured
tools and workflow. There's been some discussion of moving to GitHub.
On the pro side:
* Easier to signup and request commit access
* Most committers likely to have GitHub account for other projects
anyway
* Easier for community to fork SSG code (e.g. gitmachines project)
* Dramatically better ticketing system
- labels
- user-friendly GUI
- git commit hooks (put ticket # in patch title, auto
resolves ticket)
- multi-developer collaboration on tickets easier through
@name calls
* "Pull Request" concept: Patches centrally managed and merged,
ensures no missed patches on mailing list
* Simplified branching (e.g. allows a -stable and -dev branch).
Possible on FedoraHosted, not as intuitive
* Increased reliability of infrastructure (especially latency of
git pulls)
On the cons:
* Slight developer hassle to migrate SSH keys
* "Not hosted by RedHat" -- concern from some that migrating from a
redhat/fedora hosted URL will diminish project brand.
What does everyone think?
10 years
RHEL6 & STIG
by Steve Thomas
Hi All,
I'm in the process of implementing a lockdown of RHEL6 based on the STIG found in your packages.
I'm moving through each failure but I'd like to find out if there's a way to see what checks are actually being performed for each RuleID so that I can perform them on the command line to understand what they are looking for.
I'm also seeing 2 errors and I'd like to understand and fix those so turning on debug or verbose logging would really be useful to find out why both of these error:
* mountopt_noexec_on_removeable_partitions
* selinux_all_devicefiles_labeled
Can anyone help?
Thanks,
Steve
10 years
Lastlog Implementation
by Kayse, Josh
In working through implementing lastlog a few questions have come up.
1) Should lastlog be touched by cron?
2) Should lastlog be touched by sudo?
3) How does one reset lastlog for a user after the time has passed?
== 1) Should lastlog be touched by cron? ==
I discovered that cron interacted with lastlog because I disabled the unconfined module and cron stopped working. This is because crond_t is specified as an unconfined domain in the unconfined policy which allows it to interact with any SELinux domain.
This made me think about whether cron should even be interacting with lastlog. It would be possible for a user to create a cronjob that just runs once a day and prevents them from being marked inactive, despite any actual logins. It’s for this reason that I think the following lines should be added immediately before the pam_lastlog.so line in /etc/pam.d/system-auth and /etc/pam.d/password-auth
auth [success=1 default=ignore] pam_succeed_if.so service in crond quiet
account [success=1 default=ignore] pam_succeed_if.so service in crond quiet
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet
These lines prevent pam_lastlog.so from being called for crond.
== 2) Should lastlog be touched by sudo? ==
I think that lastlog should not be triggered by sudo either. This is because lastlog is designed for displaying and monitoring last logins of a user. An invocation of sudo is not a login and therefore should not trigger lastlog.
== 3) How does one reset lastlog for a user after the time has passed? ==
This is just for my education. Once the inactive time has passed for a user, how as a system administrator am I supposed to reset it?
Thoughts?
Thanks,
-josh
PS: In another thread on this ML, it was brought up that hand-editing the pam_d files will be unsupported. That said, authconfig-tui in Fedora does not have an option for setting up lastlog and therefore requires hand-editing of files to implement. I’m not sure if this applies to RHEL6 too, but I thought I’d point it out.
10 years
[PATCH] [RHEL/6] Don't require exact permissions on httpd directories / files (AKA allow also stronger permissions to meet the checks)
by Jan Lieskovsky
[RHEL/6] Don't require exact permissions on httpd directories / files:
* 0700 on /var/log/httpd directory
* 0750 on /etc/httpd/conf directory
* 0640 on /etc/httpd/conf/* files
But allow also systems having stronger permission requirements
on these files to meet the checks / policy.
Besides that the HTML version of the guide has spoken about 0700 mode
requirement for permissions of the /var/log/httpd directory (but in fact
the corresponding OVAL check was checking 0750 mode). This patch fixes
this inconsistency too (by making the OVAL check to check against 0700 mode).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years
audit rules and -a exit,always
by Steve Grubb
Hello,
The audit system can take rules that start with
-a always,exit
just as well as rules that start with
-a exit,always
This has been trouble for scanners because people see rules in both orders.
But people complained about this and as of the 2.0.6 release of the audit
package, all rules were in a consistent '-a always,exit' format. Someone
reported a problem on the linux-audit mail list saying they were failing a
scan. I check the SSG content and sure enough, its looking for rules in the
exit,always order. You can check it like so:
grep -rl '\-a exit\,always' *
The rules should be fixed to match only always,exit so that everything
everywhere is consistent. I would only be concerned about RHEL6/7 because
there is no possibility of changing the RHEL5 audit package to ship rules that
are consistent.
Thanks,
-Steve
10 years
MLS_CSCF profile
by Kordell, Luke T
Here is a profile I have been developing. Some of the rules within the profile contradict each other, but the future plan is to break-up this profile into a few different releases. We will eventually have an HPC, Cluster, US and generic version of this profile each with slightly different rule selections. The selinux ploicy rule will always be refined to check that selinux is implementing the mls policy type. Let me know if you have any questions or suggestions!
Luke K
10 years