-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add KSPP compliance notices to corresponding parameters and sysctls
#264
Conversation
Another area of partial compliance is regarding forcing and immediate system reboot upon a "oops":
We currently only have:
Personally I think making the system reboot by default is a good from a security stand-point but I am not sure what the scale of impact will be on end users. |
Note, we are also non-compliant when it comes to kernel warnings causing panics. This requires setting KSPP recommends immediate reboots at any oops or warn:
These two
|
@therealmate thank you for the review! These suggestions had already been applied in 56b28e3. |
😅 yeah you're right, i must have been looking at an older diff |
Great work! Could use a definition somewhere what
Suggestions welcome. I'd like to merge this rather sooner than later. Ready? Another (perhaps future work, separate PR?) could be to express security-misc KSPP compliance or non-compliance. Not sure that would make sense or any other metadata? I guess any non-compliance can be seen from the context of additional comments, is however not standardized like Not sure about |
I am not exactly sure what you mean by this? Regarding other metadata, there is no limit to the amount of fidelity that we could add but I am not sure if any of it will be that helpful to many people. We could add an equivalent 'Madaidan=yes', but given the over two years of inactivity, I do not think this is necessary despite them being a large early contributor of the settings. The only other sizable sources I can think of at the moment are you and me. I think our configs have already greatly expanded in size/lines from all the refactoring I have submitted over the last 6 weeks. Adding more metadata would certainly be helpful, but I we need a solid reason for their inclusion. On top of this there are 2 outstanding issues that I can currently conceive:
|
I mean to add some easily readable metadata comment that expresses when we deviate from KSPP recommendations. For example in human understandable terms, "KSPP recommended, yes, but not implemented by security-misc, because ...".
Best discussed in separate issues to not mix it with this big comment changes pull request. |
This is a good idea! It will definitely decrease future maintenance burden. I will think about what would be the best way to implement this. However, note that in most situations the comments surrounding a setting almost always generally explain why we diverge from the KSPP. However, it would certainly be efficient to convert this into metadata. |
This PR adds KSPP compliance notices to corresponding parameters and
sysctl
s as per #256.I have tried to be comprehensive and thorough but please re-check my work.
For the time being I have decided not to add "KSPP=no" notices as I am not sure that these would be helpful? Is there any point in showing non-compliance if we already show what is consistent with the KSPP.
Also there are two areas of of partial compliance:
Do we want to adhere to the KSPP on these?
The first is discussed in #263 and has the potential to cause breakages but I am not that familiar with its real world usage.
The second was discussed earlier in #242.
Changes
There are currently no changes to the functionality of the code.
Mandatory Checklist
Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint
Optional Checklist
The following items are optional but might be requested in certain cases.