Packit and Fedora spec file of SSG
by Matěj Týč
Hello everybody,
recently, the 5000th PR [1] of the ComplianceAsCode project landed,
proposing the Packit CI support. Packit uses the Fedora spec file [2],
i.e. source of the RPM package, in the test process.
The discussion in that PR centered around handling of the spec file - it
now became possible to have it in the repository, syncing it with the
Fedora server, or Packit would pull it from the Fedora repository
whenever it is needed. Both ways have theirs pros and cons, and as you
can read in [1], some members of the community raised concerns that the
current way of how the spec file is handled encumbers the community.
So if this is also your case, please let us know how having the spec
file upstream would change the situation for you. For the sake of
completeness, nowadays we update the package every time we make an
upstream release, and we issue a build and respective update right after.
References:
[1]: https://github.com/ComplianceAsCode/content/pull/5000
[2]:
https://src.fedoraproject.org/rpms/scap-security-guide/blob/master/f/scap...
3 years, 4 months
Re: [EXTERNAL] Re: SCAP for RaspberryPI?
by Shawn Wells
On 11/26/19 9:05 AM, Kern, Thomas (CONTR) wrote:
> Having the openscap tools available is great. I know that it is difficult to provide each distribution with SCAP control files to check for all compliance settings. It would be nice if there were SCAP control files for a 'Linux distribution independent' compliance scan, checking the setting of the most common compliance issues across all variations of Linux.
Has been discussed. Creating such content would be very cumbersome --
most linux distros keep things in different places (e.g. Fedora vs RHEL
vs Ubuntu vs SLES), or have different implementations (AppArmor vs
SELinux).
While SCAP does support if-clauses ("If SuSE, check AppArmor; elif RHEL,
check SELinux") there hasn't been a development community form to take
on that work. Patches welcome if someone wants to begin though!
3 years, 6 months
SCAP for RaspberryPI?
by Foxy Lady
Hi, as RaspberryPI is getting more and more used in amateur- and
educational IOT setups it would be very helpful to have SCAP available on
that platform, but it looks like there is no SCAP for Raspberry Pi?
I hope I am wrong?
Thanks for your help!
Have a nice day,
Foxy Lady
3 years, 6 months
RE: [EXTERNAL] Re: SCAP for RaspberryPI?
by Kern, Thomas (CONTR)
Having the openscap tools available is great. I know that it is difficult to provide each distribution with SCAP control files to check for all compliance settings. It would be nice if there were SCAP control files for a 'Linux distribution independent' compliance scan, checking the setting of the most common compliance issues across all variations of Linux.
--
Thomas Kern
Senior Linux Engineer
Security+ Certified
Office of the Chief Information Officer
On Contract to U.S. Department of Energy - CBOSS
O: 301-903-2211 | M: 301-905-6427
Thomas.Kern(a)hq.doe.gov
--
A subtlety of Murphy's Law:
If it can go wrong, it already has,
and you just haven't realized it yet.
-----Original Message-----
From: Alexander Bergmann [mailto:abergmann@suse.com]
Sent: Tuesday, November 26, 2019 8:22 AM
To: Foxy Lady <supersexycoder(a)gmail.com>
Cc: scap-security-guide(a)lists.fedorahosted.org
Subject: [EXTERNAL] Re: SCAP for RaspberryPI?
Hi,
The development of the OpenSCAP tools and the integration into a
distribution are two pair of shoes. There are so may Linux distributions
that it would make absolutely no sense to provide packages to all of
them. Furthermore, to build packages is actually part of the
distribution workflow.
I've checked and OpenSCAP is already available within Rasbian. The
following command should do the trick.
#> apt-get install libopenscap8
Regards,
Alex~
On Tue, Nov 26, 2019 at 01:13:08PM +0100, Foxy Lady wrote:
> Thanks, Alex, I had the same impression, but want to avoid having to
> maintain packages myself, there are too many things already that I have to
> maintain.
> Is there no interest in supporting Raspberry Pi by the maintainers of this
> project? I read about Raspis as the entry drug to IOT everywhere - and see
> it in educational settings, all places where it would be of extraordinary
> value to implement scap security and make people aware!
> Thank you very much for your attention!
>
> On Mon, Nov 25, 2019 at 8:52 PM Alexander Bergmann <abergmann(a)suse.com>
> wrote:
>
> > Hello Foxy Lady,
> >
> > basically the OpenSCAP tools can be compiled on any platform. I'm not
> > sure if it is directly available on Raspbian, but on openSUSE it would
> > work out of the box.
> >
> > https://en.opensuse.org/HCL:Raspberry_Pi3
> >
> > Regards,
> > Alex~
> >
> > On Mon, Nov 25, 2019 at 06:46:13PM +0100, Foxy Lady wrote:
> > > Hi, as RaspberryPI is getting more and more used in amateur- and
> > > educational IOT setups it would be very helpful to have SCAP available on
> > > that platform, but it looks like there is no SCAP for Raspberry Pi?
> > >
> > > I hope I am wrong?
> > >
> > > Thanks for your help!
> > > Have a nice day,
> > > Foxy Lady
> >
> > > _______________________________________________
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
> >
> >
> > --
> > Alexander Bergmann <abergmann(a)suse.com>
> > Security Engineer, GPG: E30A 65A4 0F50 0066 B2B5 F614 DE54 E875 9FFA 4886
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nuremberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Managing Director: Felix Imendörffer
> >
> _______________________________________________
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
--
Alexander Bergmann <abergmann(a)suse.com>
Security Engineer, GPG: E30A 65A4 0F50 0066 B2B5 F614 DE54 E875 9FFA 4886
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nuremberg, Germany
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer
3 years, 6 months
SSSD configuration checks clarification
by Ilya Okomin
Hello experts!
I've noticed SSSD configuration rules implemented without verification
if SSSD package/service installed/enabled. To be added, remediation part
doesn't install sssd in case it is missing on the system, thus fix
doesn't work for systems with no sssd on board.
Rules:
- sssd_enable_pam_services
- sssd_ldap_configure_tls_ca_dir
- sssd_ldap_start_tls
So I have couple questions for clarification on the above:
Shouldn't SSSD presence test criteria be added for mentioned rules and
just mark them as passed if no SSSD observed?
With regard to STIG profile, should service_sssd_enabled rule be added
as a requirement?
Regards,
Ilya.
3 years, 6 months
Re: removing telnet client breaks fence agents
by Vojtech Polasek
adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
> Hello all,
>
> I am fixing the following bugzilla:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1729222
>
> Brief summary: as part of several profiles, in this case NCP profile
> in rhel7, we are removing the telnet package containing the Telnet
> client.
>
> But this removal of telnet package causes removal of the
> fence-agents-all package and this causes removal of VDSM.
>
> So if an user wants to be compliant with NCP, they can't use VDSM nor
> some fence agents at the same time.
>
> I proposed a PR which removes the "package_telnet_removed" rule from
> rhel7, rhel8 and rhv4 profiles.
>
> https://github.com/ComplianceAsCode/content/pull/4958
>
> I understand that Telnet server introduces a security risk because it
> uses unencrypted traffic, it is a common port attackers scan for etc.
> We are removing the telnet-server package and also making sure that
> the telnet service is disabled in two other separate rules.
>
> But do we really need to explicitly remove also the Telnet client?
> Especially if it prevents features like VDSM from working? I
> understand that it uses unencrypted traffic as well, but is it such a
> high security risk?
>
> Steve, anyone else, could you give an opinion on this please?
>
> Thank you,
>
> Vojta
>
>
>
>
3 years, 6 months