scap-security-guide September 2018

scap-security-guide@lists.fedorahosted.org

12 participants
12 discussions

Issue with Repo GPG Checking
by Trevor Vaughan 20 Oct '18

20 Oct '18

Hi All, I've been re-roaming through the SSG and this is probably the first of a many part thread regarding different checks. TL;DR; The potential risk caused by enabling 'repo_gpgcheck' outweighs any potential benefit if TLS is enabled. In my opinion, the following check should *only* be enabled if all of your repositories are internally managed xccdf_org.ssgproject.content_rule_ensure_gpgcheck_repo_metadata. The reason for this is that YUM presently does not (to my knowledge) have any way to differentiate between package signing GPG keys and repo signing GPG keys. This means that if, for instance, I host my packages via some shared Nexus, then I have to add the Nexus GPG key to my trust list for the repo. I fundamentally do *not* want to do this! I shouldn't be allowing my Nexus maintainer to potentially install software on my system without my explicit knowledge. You should use TLS, and the repo should have a trusted certificate there and that should be sufficient for the metadata until RPM can tell the difference between these two certificates. Please let me know if I've missed something, but I don't remember seeing options to split out the two sets of certs. Additionally, this is marked as 'high' severity and that seems to be massive overkill considering that 1) the packages are still signed and validated and 2) TLS is required. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

7 20

Re: False positive message for sshd key file permission
by Reese, Brian J CTR (US) 26 Sep '18

26 Sep '18

DISA just released Version 2 Release 1 of the RHEL 7 STIG. It appears they fixed their content on this one (SV-86881r2_rule) so it should match the SSG content. -----Original Message----- From: Shawn Wells <shawn(a)redhat.com> Sent: Wednesday, September 26, 2018 11:22 AM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Subject: [Non-DoD Source] Re: EXTERNAL: Re: False positive message for sshd key file permission All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- On 9/25/18 8:45 AM, Albrecht, Thomas C wrote: > I’d leave it, since something seems to revert the permissions later back to 0640. (Probably a package update, but I haven’t researched it yet.). +1, agree with Tom. _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org Fedora Code of Conduct: Caution-https://getfedora.org/code-of-conduct.html List Guidelines: Caution-https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: Caution-https://lists.fedorahosted.org/archives/list/scap-security-guide@li…

1 0

False positive message for sshd key file permission
by Dushyant Uge 26 Sep '18

26 Sep '18

Hello Team, One of our customer raised concern that -- The rule going wrong are: xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key On the customer's system, the correct permissions seen -- Red Hat Enterprise Linux Server release 7.5 (Maipo) openssh-server-7.4p1-16.el7.x86_64 openscap-1.2.16-6.el7.x86_64 - 640 for public key files (*.pub) - 600 for private key files (*_key) Output of ls –l /etc/ssh -rw-r--r--. 1 root root 581843 Nov 24 2017 moduli -rw-r--r--. 1 root root 2276 Nov 24 2017 ssh_config -rw-------. 1 root root 4026 Sep 4 14:20 sshd_config -rw-------. 1 root ssh_keys 241 Sep 4 14:20 ssh_host_ecdsa_key -rw-r--r--. 1 root root 162 Sep 4 14:20 ssh_host_ecdsa_key.pub -rw-------. 1 root ssh_keys 1704 Sep 4 14:20 ssh_host_rsa_key -rw-r--r--. 1 root root 382 Sep 4 14:20 ssh_host_rsa_key.pub -rw-r--r--. 1 root root 2548 Sep 4 14:20 ssh_known_hosts Please find attached screenshot and suggest. Warm Regards, Dushyant Uge Red Hat Global Support

5 7

New Jenkins DNS Records
by Shawn Wells 20 Sep '18

20 Sep '18

nudge to Martin/Marek - Created new DNS entries for the jenkins systems: jenkins.complianceascode.io --> 89.221.216.197 fedora-master.jenkins.complianceascode.io --> 89.221.216.197 fedora-worker.jenkins.complianceascode.io --> 89.221.216.149 rhel7-worker.jenkins.complianceascode.io --> 89.221.216.210 rhel6-worker.jenkins.complianceascode.io --> 89.221.216.211 Let me know if others are needed! -Shawn

1 0

Re: NetworkManager Requirements
by Trevor Vaughan 17 Sep '18

17 Sep '18

On a default installation? They can't but I think they can twiddle things in NetworkManager from the GUI IIRC. But they also can't get to root via 'sudo' and we have rules for that. Polkit is basically sudo for DBus stuff and we have rules around what should, and should not, be done with sudo so I guess I expect the same thing with polkit. For instance, I could use pkexec to run arbitrary commands as root without a password if I have a rule set up for it. But, unlike sudo, there isn't a rule saying not to do that and a method to check for it. Thanks, Trevor On Mon, Sep 17, 2018 at 9:45 AM Thomas Haller <thaller(a)redhat.com> wrote: > On Mon, 2018-09-17 at 09:19 -0400, Trevor Vaughan wrote: > > Otherwise, there's a > > lovely gaping hole in the system security that can effectively be > > used to run pretty much anything with root permissions. > > Hi, > > This makes me wonder. How can an unpriviledged user get root > permissions on a default installation of RHEL? Either in general, or > specifically using NetworkManager. > > > best, > Thomas > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

3 10

Re: NetworkManager Requirements
by Matus Marhefka 17 Sep '18

17 Sep '18

Hello Thomas, thank you for the clarification, we appreciate your help. @Trevor: Do you have any more questions considering NetworkManager requirements? As Thomas and Lubomir are in the thread it would be best to discuss and clarify with them. Best Regards, Matus On Mon, Sep 10, 2018 at 4:44 PM Thomas Haller <thaller(a)redhat.com> wrote: > On Mon, 2018-09-10 at 15:02 +0200, Matus Marhefka wrote: > > Hi, > > > Hello Thomas, Lubomir, can you help us on this topic? There are some > > questions which we (Security Compliance team) are unable to answer > > and we need your help: > > > > 1. Is NetworkManager meant to be a required service in RHEL 7? > > No, it is not required. > > > > 2. What is the proper mechanism for restricting DBus access to > > NetworkManager to only allowed users (i.e. no GUI utilities, etc...)? > > Do you have any pointers (manuals/blogs/...)? > > It's not in particular about GUI utilities. All NetworkManager clients > use the D-Bus API of NetworkManager. > > Clients are authenticated as the (user of the) process that is talking > to NetworkManager's D-Bus (e.g. the user who invokes nmcli). > > Note that requests from user id 0 (root) are always allowed by > NetworkManager. All other Requests are autorized using PolKit [1]. See > the .policy file ([2], [3]) for the actions available to > NetworkManager. > > Configuring authorization with PolKit is AFAIK done by writing rules. > But how to do that correctly, please ask PolKit maintainers. > > > [1] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html > [1] /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy > [2] > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/org.fr… > > > I am not aware of issues regarding hidepid [3]. But probably such > configuration is little tested and used. As far as NetworkManager is > concerned, it should work. I don't know what PolKit makes of that, > worst case it will reject the request (as said: requests from root are > not authorized via PolKit). > > [3] https://bugzilla.gnome.org/show_bug.cgi?id=764502 > > > best. > Thomas > > > > > Thanks, > > Matus Marhefka > > > > > > On Sun, Sep 9, 2018 at 6:57 PM, Trevor Vaughan < > > tvaughan(a)onyxpoint.com> wrote: > > > Oh, this is also related to the 'hidepid' discussion. If > > > NetworkManager is going to be a blocker on hidepid, then it needs > > > to be fully locked down and I can't find good guidance on doing > > > that. > > > > > > On Sun, Sep 9, 2018 at 12:56 PM Trevor Vaughan < > > > tvaughan(a)onyxpoint.com> wrote: > > > > Everyone I know hates that on servers. > > > > > > > > Apparently firewalld tries to use it and it's mentioned in the > > > > SSG explicitly. > > > > > > > > Since it's mentioned, there needs to be surrounding guidance on > > > > how to make it not be so "user friendly". > > > > > > > > If it's not needed, it should fall under "run no unnecessary > > > > services" and be slated to be killed explicitly since it does try > > > > to give people the ability to do things in the network stack by > > > > default (which they should not have). > > > > > > > > Thanks, > > > > > > > > Trevor > > > > > > > > On Sat, Sep 8, 2018 at 12:38 PM Matthew <simontek(a)gmail.com> > > > > wrote: > > > > > Why is NetworkManager required? I hate that on servers. > > > > > > > > > > On Fri, Sep 7, 2018, 5:42 PM Trevor Vaughan < > > > > > tvaughan(a)onyxpoint.com> wrote: > > > > > > As I was digging around some of the content, I realized that > > > > > > I had a question that I never managed to get answered. > > > > > > > > > > > > Namely, is NetworkManager now a required service? > > > > > > > > > > > > If so, what is the proper mechanism for restricting DBus > > > > > > access to NetworkManager to only allowed users (i.e. no GUI > > > > > > utilities, etc...). > > > > > > > > > > > > I feel like this should be codified somewhere in the SSG > > > > > > content. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Trevor > > > > > > > > > > > > -- > > > > > > Trevor Vaughan > > > > > > Vice President, Onyx Point, Inc > > > > > > (410) 541-6699 x788 > > > > > > > > > > > > -- This account not approved for unencrypted proprietary > > > > > > information -- > > > > > > _______________________________________________ > > > > > > scap-security-guide mailing list -- > > > > > > scap-security-guide(a)lists.fedorahosted.org > > > > > > To unsubscribe send an email to > > > > > > scap-security-guide-leave(a)lists.fedorahosted.org > > > > > > Fedora Code of Conduct: > > > > > > https://getfedora.org/code-of-conduct.html > > > > > > List Guidelines: > > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > List Archives: > > > > > > > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > > > > > > > _______________________________________________ > > > > > scap-security-guide mailing list -- > > > > > scap-security-guide(a)lists.fedorahosted.org > > > > > To unsubscribe send an email to > > > > > scap-security-guide-leave(a)lists.fedorahosted.org > > > > > Fedora Code of Conduct: > > > > > https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > > > > > > > > > -- > > > > Trevor Vaughan > > > > Vice President, Onyx Point, Inc > > > > (410) 541-6699 x788 > > > > > > > > -- This account not approved for unencrypted proprietary > > > > information -- > > > > > > >

2 1

NetworkManager Requirements
by Trevor Vaughan 10 Sep '18

10 Sep '18

As I was digging around some of the content, I realized that I had a question that I never managed to get answered. Namely, is NetworkManager now a required service? If so, what is the proper mechanism for restricting DBus access to NetworkManager to only allowed users (i.e. no GUI utilities, etc...). I feel like this should be codified somewhere in the SSG content. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

3 5

Suggesting adding hidepid=2 on /proc to the SSG
by Trevor Vaughan 07 Sep '18

07 Sep '18

I've had this feature request open for a while at https://github.com/OpenSCAP/scap-security-guide/issues/1648 suggesting that hidepid=2 be added to /proc to help meet the AC-3 and AC-6 controls. As we approach EL8 (I think), I'd like to have this discussion since this capability has shown to be valuable in a practical way on multi-user systems. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

3 6

Re: [Open-scap] Ensure that official distribution repositories are used check failed in Debian 8
by Marek Haicman 07 Sep '18

07 Sep '18

Hello Dhanushka, first of, I added scap-security-guide list, as that will make more sense for this kind of questions. open-scap-list is mostly about scanner issues (and in 99% cases, problem is in content, not in the scanner). Regarding the problem itself, it would be great if you took a look at the sources for the oval, maybe you'll be able to find the issue yourself. As you are on the platform. To find the source for the issue, I have checked the ID of the rule is rule_apt_sources_official. So calling this in cloned git repo: `find . | grep apt_sources_list` will tell you where are the sources: ./linux_os/guide/services/apt/apt_sources_list_official/oval/shared.xml is the source for check. There is no complexity, there just regexes, so if you find an issue, pull request with the fix would be awesome, but explanation what is the bug will also do. Thanks! Marek On 09/07/2018 07:38 AM, Dhanushka Parakrama wrote: > Hi Team > > In Debian 8 */etc/apt/sources.list *file include below repositories > > deb http://ftp.us.debian.org/debian/ jessie main > deb-src http://ftp.us.debian.org/debian/ jessie main > > deb http://security.debian.org/ jessie/updates main > deb-src http://security.debian.org/ jessie/updates main > > but still *oscap xccdf eval --profile > xccdf_org.ssgproject.content_profile_anssi_np_nt28_high --report > report.html ssg-debian8-ds.xml * Scan says > > image.png > > *Ensure that official distribution repositories are used * -> *FAIL* > Is there any reason for that ? > > Thank You > Dhanushka > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list >

1 0

new home of SCAP Security Guide
by Marek Haicman 06 Sep '18

06 Sep '18

Hello fans of SCAP and security content, some of you might have noticed that there is a new repository `github.com/ComplianceAsCode/content`. tl;dr: SCAP Security Guide implies strong ties to the SCAP format. Over time the project evolved and is now format-agnostic. To avoid confusion we decided to rename the project. Even though SCAP Security Guide started purely as a producer of SCAP formatted data, if you take a look at the README from that time, it quite clearly expresses the real idea behind it. I will quote one part, full is available [1] """ This project is an attempt to allow multiple organizations to efficiently develop such content by avoiding redundancy, which is possible by taking advantage of features of the SCAP standards. """ The SCAP was there as a means of collaboration. While SCAP is great idea on the paper, in practice it often falls short. Especially OVAL can be quite challenging as a common language. It's hard to use, domain specific and declarative. These design choices prevent it from having a broader appeal. This is my personal opinion, but I believe it's shared by most contributors. Past experience also made it quite obvious that no single language or format will satisfy everybody. Additionally, there is no single format suitable for every platform. As a result, we have expanded the scope of SSG to support Bash remediation roles, Ansible, puppet. We have also made the build system adaptable and flexible. This opens doors to more formats and languages in the future. With these changes in place, we felt like it was imprecise to have SCAP in the name. Treat "content" as an interim name for now. The important part is the move to the "ComplianceAsCode" organization. We believe it better encompasses our vision of the project. We are in process of finding ourselves better name. It is proving difficult to find a name that is fitting and likeable so we don't have an ETA yet. Please bear with us. From the perspective of the project, nothing changes - CI is the same, maintainers are the same, focus is the same. It is just a name change, but with a big message. And we hope you are happy about the change. Let's start a new chapter in this project's rich history together. We will also be more than happy for any question or feedback on this change. Thank you for your support, Marek on behalf of ComplianceAsCode/content [1] https://github.com/ComplianceAsCode/content/tree/2ef5b750a76b450171f5badbff…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide September 2018