Proposal to add new constructs to AIX schema

[wmunyan]

A number of recommendations in CIS benchmarks deal with the collection and evaluation of AIX security parameters. This proposal adds the lssec_(test|object|state|item) constructs, allowing for the collection and evaluation of these parameter values.

This construct is based on the invocation and evaluation of the lssec command for AIX, documented HERE.

[wmunyan]

UPDATES:

• Renamed the lssec_test to securitystanza_test so as to not name the test after the command being executed and hopefully help be more descriptive.
• Added new tests to aid in implementation (pretty much in line with what would be needed to implement CIS AIX benchmark):
  • deviceattribute_test: Displays attribute characteristics and possible values of attributes for devices in the system
  • inittab_test: Lists records in the /etc/inittab file.
  • useraccount_test: Displays user account attributes
  • nfso_test: Manages Network File System (NFS) tuning parameters

[solind]

Hi @wmunyan , the diff isn't very clean -- for example, it looks like the no_test was deleted and re-added (possibly changed?). Are your changes really limited to the new nsfo, useraccount, inittab, deviceattribute and securitystanza tests?

[wmunyan]

@solind that IS weird... Yes my changes are limited to the new tests. I didn't alter any existing stuff.

[solind]

Hi @wmunyan , do you have any content using these new tests? "Test" content (like, meaningless except to determine whether the check works correctly) is fine.

[wmunyan]

@solind I attached some test content to the proposal. Hopefully its correct :)

[johnulmer-oval]

Having read through the schema and example content, these new tests (securitystanza, deviceattribute, inittab, useraccount, and nfso) look good. I concur with the splitting the lssec approach into more targeted single use tests. This helps avoid complications and ambiguity in implementations (OVAL content authoring and SCAP processor coding).

[wmunyan]

@johnulmer-oval I just wanted to get some clarification on your comment above. You mention:

I concur with the splitting the lssec approach into more targeted single use tests

I was curious what you meant there. I had a couple of bad comments in there (cut/paste issues, admittedly) where the term lssec was used in some of the other tests, but the lssec command should only be used in the securitystanza test, and hasnt been split into multiple tests. There's just the one that maps to usage of lssec.

I could be overthinking, so if you are simply good with the proposal as-is, let me know of that and I can get it merged into the development branch.

[johnulmer-oval]

Hey Bill, If I understand the history of these tests, they started out as a single test/object/state which were split out into the several more targeted tests.  My comment was simply support for that kind of test design.  More a comment on the approach than the specific tests. I surfed the test/object/state schema and worked through the basics of pulling the required system characteristics on our AIX machine and it looked good.  Hope that clarifies the comment sufficiently. Thanks. John On 9/13/2021 9:41 AM, Bill M wrote: @johnulmer-oval I just wanted to get some clarification on your comment above. You mention: I concur with the splitting the lssec approach into more targeted single use tests I was curious what you meant there. I had a couple of bad comments in there (cut/paste issues, admittedly) where the term lssec was used in some of the other tests, but the lssec command should only be used in the securitystanza test, and hasnt been split into multiple tests. There's just the one that maps to usage of lssec. I could be overthinking, so if you are simply good with the proposal as-is, let me know of that and I can get it merged into the development branch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#126 (comment)", "url": "#126 (comment)", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[wmunyan]

@johnulmer-oval so then just for confirmation, you're OK for us to merge this PR into the development branch?

[slarchacki22]

Hi, I think with the need to have to change the meeting invite for the bi-weekly Area Supervisors meeting, today's meeting was very light. We plan to table the discussion on this until the next meeting. Thanks!

[vanderpol]

@solind or @johnulmer-oval , just checking on the status of this PR, should it be pulled into the develop branch, and included in OVAL 5.12? Thanks!

[solind]

I'm pretty sure these changes were actually implemented in Joval, but someone at AWN should verify. @maxullman @A-Biggs

[maxullman]

@solind I don't think Joval has implemented them, I don't see them. Joval implemented the other AIX tests including some which this PR removes. I don't think AWN has much of an interest in AIX but I will say having worked on an AIX Benchmark the stanza test would have been nice to have compared to the convoluted tfc test we used instead.

[solind]

Yeah, @maxullman , it's been a while, maybe I didn't implement the object collectors. But I did pull those changes into the schema Joval used to use:
https://github.com/joval/jOVAL/blob/master/scap/schemas/oval/unofficial/aix-def-schema.xsd

[vanderpol]

Given the ever dwindling usage of AIX in the wild, I feel like we are adding new tests that we are likely going to mark as deprecated in the very near future, but I'll proceed with the pull request. We dropped support for AIX 5+ years ago and have never had anyone ask for the sunset version of SCC for AIX.