OpenSCAP / openscap-daemon

Manages continuous scans of your infrastructure
https://www.open-scap.org/tools/openscap-daemon
GNU Lesser General Public License v2.1
106 stars 32 forks source link

container/remediate.py: cleanup of repository data inside remediated image #114

Closed matusmarhefka closed 6 years ago

matusmarhefka commented 6 years ago
pep8speaks commented 6 years ago

Hello @matusmarhefka! Thanks for updating the PR.

Line 79:47: E225 missing whitespace around operator Line 145:80: E501 line too long (80 > 79 characters)

Comment last updated on October 16, 2017 at 14:59 Hours UTC
matusmarhefka commented 6 years ago

Commit 442de15 fixes PEP8 issue with except.

jan-cerny commented 6 years ago

@matusmarhefka I think there can be a better way to do this. Starting a new container looks like a unnecessary overhead. Have you considered some other options?

matusmarhefka commented 6 years ago

@jan-cerny I considered only looking at the image labels, but that is not very reliable. Do you have some other suggestions?

jan-cerny commented 6 years ago

Hmmm, when I run yum on Fedora, it calls dnf

matusmarhefka commented 6 years ago

@jan-cerny That is true, it is provided by dnf-yum package and it links yum command to dnf command. We can hardcode container/remediate.py to use yum, but in the future you might need to solve this issue anyway if we want to harden also other images than RHEL/Fedora.

jan-cerny commented 6 years ago

@matusmarhefka That's also true. So we might want to solve this issue completely.

There are two things that can be useful:

  1. The fix.sh script usually installs some packages. So it often contains "apt-get install" or "dnf install". That can be easier to analyse, but not completely reliable.

  2. Better option could be the fact that this script will get a path to results directory as an argument. The directory contains ARF. The ARF contains information about target container. You can parse the ARF to get the information. Most likely CPE will help you.

matusmarhefka commented 6 years ago

We discussed with @jan-cerny and the best solution seems to be to look at platform CPE in ARF results. Checking fix.sh script is unreliable as it contains code which is deciding between dnf or yum commands directly in a container during remediation.

I will update the PR to determine package manager by looking at platform CPEs in ARF results file.

matusmarhefka commented 6 years ago

Commit c0814e0 updates code to work with platform CPE which is obtained from ARF results file.

matusmarhefka commented 6 years ago

Commit e0d5012 uses xml.etree.ElementTree instead of lxml.

jan-cerny commented 6 years ago

@matusmarhefka Great! Thank you :D