recently, the 5000th PR  of the ComplianceAsCode project landed,
proposing the Packit CI support. Packit uses the Fedora spec file ,
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 , 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.
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
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!
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,
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.
Senior Linux Engineer
Office of the Chief Information Officer
On Contract to U.S. Department of Energy - CBOSS
O: 301-903-2211 | M: 301-905-6427
A subtlety of Murphy's Law:
If it can go wrong, it already has,
and you just haven't realized it yet.
From: Alexander Bergmann [mailto:email@example.com]
Sent: Tuesday, November 26, 2019 8:22 AM
To: Foxy Lady <supersexycoder(a)gmail.com>
Subject: [EXTERNAL] Re: SCAP for RaspberryPI?
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
I've checked and OpenSCAP is already available within Rasbian. The
following command should do the trick.
#> apt-get install libopenscap8
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
> 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>
> > 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://firstname.lastname@example.org...
> > --
> > 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://email@example.com...
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
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.
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?
adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
> Hello all,
> I am fixing the following bugzilla:
> Brief summary: as part of several profiles, in this case NCP profile
> in rhel7, we are removing the telnet package containing the Telnet
> 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.
> 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,