[RFC] Some Considerations for Kernel Module Checks
Jeffrey Blank
blank at eclipse.ncsc.mil
Fri Jan 18 17:12:54 UTC 2013
Yes -- I think it got lost in the shuffle.
Standardizing on language/method here is desirable, and I'm afraid I
don't recall any original motivations for particular choices (or if
these were intentional).
It's possible that we chose /bin/true in order to quiet down some boot
scripts. Using /bin/false certainly seems more desirable, assuming
there are no undesirable side effects. Testing and patches welcome!
On 01/13/2013 11:17 PM, Shawn Wells wrote:
> On 12/14/12 6:45 PM, Mike Palmiotto wrote:
>> There was some discussion a while back about the proper method for
>> doing kernel module checking. (see:
>> https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-August/001384.html)
>>
>>
>> The OVAL checks for disabling kernel modules are currently checking
>> for `install [module] /bin/true`.
>>
>> I'm sure there is a reason for doing this as opposed to `install
>> [module] /bin/false`. Just a shot in the dark: we want the install to
>> fail and return as if a failure is expected? Would it make more sense
>> to run /bin/false, as the actual install is failing to install?
>>
>> Additionally, it seems the checks are using a mixture of `install
>> [module] /bin/true` and `alias [module] off`. Should these be made
>> uniform, or is there a reason for the variation in method?
>>
>> Any and all insight is greatly appreciated.
>
> Did this get lost in the pre-Christmas shuffle? I can't find any
> responses to this =/
>
> I'd wager existing code is mixed simply because there was no
> standardized approach and we needed to "just get it done" between
> multiple coders. Standardizing on /bin/false seems ideal to me. Anyone
> have strong opinions on this?
>
> And Mike was that you volunteering to submit patches for this?... ;)
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
More information about the scap-security-guide
mailing list