Skip to content
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

Teach the script about target architecture and kernel version #9

Closed
wants to merge 5 commits into from

Conversation

Projects
None yet
3 participants
@tyhicks
Copy link
Contributor

tyhicks commented Jan 12, 2019

Some recommendations are dependent on the processor architecture and/or the kernel version. For example, the KSPP recommendations differ between x86_32 and x86_64. Additionally, option names change over time such as when CONFIG_CC_STACKPROTECTOR_STRONG was renamed.

This pull request adds the ability to reason about the architecture and version when constructing the checklist. It also teaches the script about x86_32, arm, and arm64 specific config recommendations.

tyhicks added some commits Jan 11, 2019

Make the script aware of target architecture and kernel version
Add the ability to parse the processor architecture and kernel version
from the config file. The user can override the architecture and version
with the -a and -k options. Additionally, if the user wants to use the
-p option to print the recommendations without specifying a kernel
config file, the -a and -k options can be used to print the
recommendations that correspond to the specificied architecture and
version.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Warn if the architecture is not supported
Some recommendations are architecture specific so we need to warn the
user if they're checking a kconfig for an architecture that doesn't have
any architecture specific recommendations.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Add support for i386, arm, arm64
Conditionalize the checklist construction based on architecture.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Conditionalize checklist on kernel version
Add checks based on the target kernel version.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Update kspp-recommendations.config to look like a 4.20 config
Update the stackprotector related options to reflect the >= 4.18 names
and add a header that will make the checker script think that it is
dealing with a x86_64 4.20 config file.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
@tyhicks

This comment has been minimized.

Copy link
Contributor Author

tyhicks commented Jan 12, 2019

I verified that all the example configs in config_files/ show the same number of config check failures before and after these changes are applied. Of course, the ordering of the options are changed since the ordering used to construct the checklist has been changed.

@a13xp0p0v

This comment has been minimized.

Copy link
Owner

a13xp0p0v commented Jan 12, 2019

Hello @tyhicks ,

Thank you very much for this pull request! Great!

I briefly looked through the patches and I would like to discuss the approach with you before we proceed.

  1. Generally I like the way you introduce SUPPORTED_ARCHS. I also like that the script will have this '-a' argument, it's a good idea. I will look closer to this code.

  2. It looks to me that introducing kernel versions will bring more troubles than profit.
    In fact all these options have a special version when they appeared in the mainline. Some of them were renamed as well. So if we make the script aware of kernel versions, we will have to add full knowledge about them, but I don't think that it's useful.
    IMO it's better to check the config against the recent mainline options and support renamed ones using the OR operator. If the user checks some old config with the script, we will print the errors for hardening options which appeared later, and it is nice. Maybe that will even encourage the user to update the kernel for getting these new hardening features.
    What do you think?

May I ask you to extract arch support into a separate pull request? We will work further to merge it.

Thanks again for your time!

@tyhicks

This comment has been minimized.

Copy link
Contributor Author

tyhicks commented Jan 12, 2019

Thank you very much for this pull request! Great!

Glad that you find it useful. I plan to use the script and these changes to audit all of the Ubuntu kernel configs and enable reasonable hardening options that aren't yet enabled.

It looks to me that introducing kernel versions will bring more troubles than profit.
In fact all these options have a special version when they appeared in the mainline. Some of them were renamed as well. So if we make the script aware of kernel versions, we will have to add full knowledge about them, but I don't think that it's useful.
IMO it's better to check the config against the recent mainline options and support renamed ones using the OR operator. If the user checks some old config with the script, we will print the errors for hardening options which appeared later, and it is nice. Maybe that will even encourage the user to update the kernel for getting these new hardening features.
What do you think?

To be honest, I expected that you'd dislike the kernel version checking. I am on the fence about its usefulness, as well. It currently doesn't add much functionality on top of what OR() already provides. My long term thought was to extend minimum version checks to all the options (it really isn't too difficult to do that) so that I could then run the script on old Ubuntu kernel configs, such as the 3.13 kernel in Ubuntu 14.04 LTS, and get clean output that doesn't have a bunch of false negatives for that old kernel.

Maybe I'll just drop the version checking now and, in the future, propose some type of external overrides file that lets me ignore the false negatives when running against a given version of an old kernel. Additionally, this would let me specify overrides for certain options that we simply can't enable in a general purpose distro kernel.

May I ask you to extract arch support into a separate pull request? We will work further to merge it.

Certainly. It might not happen today but I'll get a new PR up very soon.

@tyhicks

This comment has been minimized.

Copy link
Contributor Author

tyhicks commented Jan 12, 2019

@a13xp0p0v I have a slightly unrelated question about the script that I'll ask here since I mentioned using this script with our Ubuntu kernel configs. What does ubuntu18 mean in the decision column of the script output? I assume that you're talking about Ubuntu 18.04 LTS but it feels like kspp should be used for nearly all of those rows instead of ubuntu18 as I consider the KSPP project as the "upstream" that makes these recommendations.

@a13xp0p0v

This comment has been minimized.

Copy link
Owner

a13xp0p0v commented Jan 13, 2019

Glad that you find it useful. I plan to use the script and these changes to audit all of the Ubuntu kernel configs and enable reasonable hardening options that aren't yet enabled.

Nice. I want this script to serve all your needs out of the box.

To be honest, I expected that you'd dislike the kernel version checking. I am on the fence about its usefulness, as well. It currently doesn't add much functionality on top of what OR() already provides. My long term thought was to extend minimum version checks to all the options (it really isn't too difficult to do that) so that I could then run the script on old Ubuntu kernel configs, such as the 3.13 kernel in Ubuntu 14.04 LTS, and get clean output that doesn't have a bunch of false negatives for that old kernel.

Ok, I see. In other words we need some functionality for categorizing and muting script errors, right?

I face a similar task as well and currently I solve it manually:

  1. check some kernel config using the script;
  2. copy errors from the report to a separate file and annotate each error. Examples:
    • this option doesn't exist in that old kernel version,
    • enabling/disabling this option breaks the user requirement (e.g. some users need HIBERNATION),
    • enabling/disabling this option breaks some code (e.g. enabling STATIC_USERMODEHELPER breaks systemd workflow on Ubuntu 18),
    • this option is not enabled since the feature is controlled via kernel command line param (e.g. CONFIG_LEGACY_VSYSCALL_NONE is not set, but the kernel command line has vsyscall=none),
    • and finally some errors are marked with TODO.

Maybe I'll just drop the version checking now and, in the future, propose some type of external overrides file that lets me ignore the false negatives when running against a given version of an old kernel. Additionally, this would let me specify overrides for certain options that we simply can't enable in a general purpose distro kernel.

Yes, let's create that!

I see two approaches:

  • Support the formatted comments in the kernel config. The script will parse them and mute/annotate the errors in its report.
  • Support formatted annotations in a separate file. We will run ./kconfig-hardened-check.py -c config -a annotations and have a pretty report.

What do you think?

May I ask you to extract arch support into a separate pull request? We will work further to merge it.

Certainly. It might not happen today but I'll get a new PR up very soon.

Thank you! Take your time, we are not in a hurry.

I have a slightly unrelated question about the script that I'll ask here since I mentioned using this script with our Ubuntu kernel configs. What does ubuntu18 mean in the decision column of the script output? I assume that you're talking about Ubuntu 18.04 LTS but it feels like kspp should be used for nearly all of those rows instead of ubuntu18 as I consider the KSPP project as the "upstream" that makes these recommendations.

The decision column helps me to maintain the list of recommendations.

The values in decision column have this "rank" for me:

  1. ubuntu18
  2. kspp
  3. grsecurity and lockdown
  4. my

So I use:

  • ubuntu18 for hardening recommendations already adopted by Ubuntu 18.04 LTS,
  • kspp for hardening recommendations that are listed in KSPP recommended settings but not adopted by Ubuntu 18.04 LTS,
  • grsecurity for cut_attack_surface recommendations from their patch which are not in KSPP recommended settings list,
  • lockdown for cut_attack_surface functionality from the lockdown patch series which is not mentioned in KSPP recommended settings list,
  • my for hardening recommendations which I consider reasonable, but others don't mention.

Thanks for your question, I think I should document that in the README.

@Bernhard40

This comment has been minimized.

Copy link

Bernhard40 commented Jan 13, 2019

@a13xp0p0v isn't better to make kspp as base for recommendations instead of ubuntu18? As @tyhicks mentioned the current order takes it backwards . The alternative would be to use defconfig here. I understand that ubuntu18 is your personal choice but it's highly opinioniated.

@a13xp0p0v

This comment has been minimized.

Copy link
Owner

a13xp0p0v commented Jan 14, 2019

@Bernhard40 , thanks for a reasonable comment. I will use defconfig as the basis.

@tyhicks

This comment has been minimized.

Copy link
Contributor Author

tyhicks commented Jan 14, 2019

Closing this pull request in favor of #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.