Hi, I would like to follow up discussions from devconf.cz regarding SCAP cockpit integration.
For now I think we are better off starting with a very basic integration and building more on top in the future. There are talks about the future of SCAP results archival, diffing, etc. but right now we don't have anything ready to be used for this integration. Just scheduling a scan and getting a result file back is enough for this stage IMO.
The following form "fields" are needed to perform a single machine evaluation:
- Target machine - I assume this will be provided by the cockpit UI itself.
- Content file - By default scap-security-guide will be selected. - Allow option to upload any content in datastream form (a single file).
- Tailoring file - Optional - can be empty and ignored - Allow upload of a single xml file. - Can only be uploaded and processed after Content is uploaded. - Affects list of available profiles but can only add more profiles.
- Checklist - Which Benchmark from given datastream will be evaluated. - In most cases there is only one Benchmark. - Select the first checklist by default.
- Profile - There will be one or more profiles in any given benchmark. - Profile decides which rules are selected and which values are used for evaluation (password size, e.g.). - Select the first profile by default.
By default when the form loads it will be populated with usable values. Scan can be performed immediately without any manual changes.
After user submits the request to evaluation `oscap` will be run with parameters generated according to the form field values. Results can be collected as XCCDF results and displayed as HTML report (openscap provides tools to make HTML report from XCCDF result).
I don't think it makes sense to implement customization / tailoring in cockpit, as well as "Save as RPM" and several other features from scap-workbench. Users can tailor in a separate application and then just use the tailoring file.
Inspiration, prior work: 1) Spacewalk SCAP integration - http://isimluk.livejournal.com/1027.html - https://fedorahosted.org/spacewalk/wiki/Scap
2) scap-workbench - GUI application that allows people to scan local or remote machines. - install in Fedora : # yum install scap-workbench scap-security-guide - user manual: https://fedorahosted.org/scap-workbench/raw-attachment/wiki/UserManual/user_...
My questions are: 1) Can cockpit schedule future actions? Does it have cron-like functionality? 2) Does cockpit have means to schedule "actions" on multiple machines at once? Or do we have to implement this specifically for the plugin to get the functionality?
Please let me know how to proceed. Should I make a graphical mockup of the GUI? I don't think I am the right person for that but I may try.
Martin Preisler mpreisle@redhat.com writes:
For now I think we are better off starting with a very basic integration and building more on top in the future.
That's the only way. :-)
As you know, Cockpit is gaining support for plugins: Eventually, people will be able to develop and release a Cockpit plugin independently and when someone installs it on a machine (with help from Cockpit), it will show up in the Cockpit UI.
If we had plugin support already now, SCAP would be done as a plugin. We don't, but you don't have to wait.
The server side of a Cockpit plugin is one or more D-Bus APIs and the UI is some HTML/CSS/JavaScript that talks to those APIs.
If you make a D-Bus API for SCAP, we can whip up some UI that talks to it from inside Cockpit. We would evolve the UI code into a plugin, and then hand it over to you.
The following form "fields" are needed to perform a single machine evaluation:
- Target machine
- I assume this will be provided by the cockpit UI itself.
Yes. Cockpit takes care of accessing the target. You only need to provide a D-Bus service locally on the target.
- Content file
- Tailoring file
- Checklist
- Profile
By default when the form loads it will be populated with usable values. Scan can be performed immediately without any manual changes.
The first version of the UI (and associated D-Bus API) could even omit these fields and simple use the defaults.
After user submits the request to evaluation `oscap` will be run with parameters generated according to the form field values. Results can be collected as XCCDF results and displayed as HTML report (openscap provides tools to make HTML report from XCCDF result).
Is it feasible to report the results XCCDF (or as JSON) and then create the HTML inside Cockpit? I would imagine that this gives a much nicer user experience.
My questions are:
- Can cockpit schedule future actions? Does it have cron-like
functionality?
No.
- Does cockpit have means to schedule "actions" on multiple machines
at once? [...]
No.
Right now, Cockpit is conceptually similar to a SSH session on a single machine, but with buttons instead of a command line shell.
Please let me know how to proceed. Should I make a graphical mockup of the GUI? I don't think I am the right person for that but I may try.
A mockup sounds good. Andreas?
cockpit-devel@lists.fedorahosted.org