docs: add production security hardening recommendations#1972
Conversation
jaihindy
requested review from
anujm1,
koenkooi,
lumag,
ndechesne,
ricardosalveti,
sbanerjee-quic and
vkraleti
as code owners
|
I think this should be in a new document and referenced in the README, since it's more suited to advanced use cases. The README is the first impression users have of the layer and should be simple and minimalist. |
lumag
left a comment
lumag
left a comment
There was a problem hiding this comment.
Also please make sure to wrap too long lines.
| Disable via kernel config: | ||
| ```text | ||
| CONFIG_DEBUG_FS | ||
| ```` |
There was a problem hiding this comment.
What does this mean? Please document the actual steps to disable debugfs
|
|
||
| Steps: | ||
|
|
||
| * Edit your distro configuration file (for example, `conf/distro/<your-distro>.conf`). |
There was a problem hiding this comment.
Is editing qcom-distro.conf a recommended way of enabling hardened config?
| ```sh | ||
| bitbake <image-name> | ||
| ``` | ||
| * Verify hardening options in the kernel `.config` (expected to be set to `y`), for example: |
There was a problem hiding this comment.
Where is the .config located?
|
|
||
| ```text | ||
| printk.devkmsg={on,off,ratelimit} | ||
| ``` |
|
|
||
| ```sh | ||
| sudo sysctl -w kernel.kptr_restrict=2 | ||
| ``` |
There was a problem hiding this comment.
How to enable it by default?
|
|
||
|
|
||
|
|
||
|
|
|
|
||
| ### 4. Signed module loading enforcement | ||
|
|
||
| Signed module loading enforcement is currently disabled. As part of commercialization/production hardening, this check should be enabled to prevent loading unsigned kernel modules. |
| * `0` = no restriction (any user can read dmesg) | ||
| * `1` = restricted (only root can read dmesg) (**recommended for production**) | ||
|
|
||
| To enforce at boot, set `/proc/sys/kernel/dmesg_restrict` to `1` (for example, from an init/startup script). You can also set it at runtime with: |
|
Why are we changing readme for this? We should probably have this as a dedicated page under a docs folder or similar. Create a dedicated md and point it from our main readme. |
Thanks for the suggestion. I’ll move this content into a dedicated markdown document (and link it from the main README) to keep the README high‑level. Please let me know if you have a preferred location for the doc. |
A folder like 'docs' would be fine, we are using something similar at https://github.com/qualcomm-linux/meta-qcom-3rdparty/tree/main/docs. |
|
closing this PR , As suggested I'll create the PR - https://github.com/qualcomm-linux/meta-qcom-3rdparty/tree/main/docs. |
|
Why? The comment was not about moving the document to |
|
Yup, the 3rdparty link was just to give an example. |
jaihindy
force-pushed
the
jaihindy-security-recommendation
branch
3 times, most recently
from
ca5ac5b to
2df0f42
Compare
lumag
left a comment
lumag
left a comment
There was a problem hiding this comment.
PLease go through the previous feedback and implement it.
Test run workflowTest jobs for commit 2df0f42a258b842323298a7a9c8c848640392f62
All jobs summary
|
Test Results 62 files - 2 268 suites - 18 3h 12m 16s ⏱️ - 15m 52s For more details on these failures, see this check. Results for commit 2df0f42a. ± Comparison against base commit 5e5f490. This pull request removes 2 tests. |
| For example, in meta-qcom CI configurations, setting: | ||
|
|
||
| ```text | ||
| DEBUG_BUILD = "0" |
There was a problem hiding this comment.
This is already set by default.
| CONFIG_DEBUG_FS=n | ||
| ```` | ||
|
|
||
| This can be achieved by updating the kernel defconfig or by applying a kernel configuration fragment in the Yocto build. |
There was a problem hiding this comment.
Provide exact steps. You are not writing a generic training. This is a part of the meta-qcom, so you should be describing steps which are applicable to meta-qcom.
| Rate limiting for kernel log output (for example via `/dev/kmsg` or the serial console) can be configured using kernel command-line parameters. | ||
|
|
||
| For production builds, enabling printk rate limiting is recommended to avoid excessive kernel log exposure. This is typically configured via the | ||
| kernel command line set by the bootloader or Yocto kernel command line configuration. |
|
|
||
| For commercial/production builds, it is recommended to set this to restrict kernel pointer visibility to privileged users only. | ||
|
|
||
| This should be enabled by default using persistent sysctl configuration (as part of the image), rather than manual runtime commands. |
jaihindy
force-pushed
the
jaihindy-security-recommendation
branch
from
2df0f42 to
47c372d
Compare
|
Thanks a lot for the feedback. I’ve updated the document to make the guidance meta-qcom specific, clarified the exact configuration mechanisms, and removed examples that are already default. |
Document recommended security settings for production devices, including kernel hardening, logging restrictions, signed module enforcement, DebugFS handling, and ADB access limitations. Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
jaihindy
force-pushed
the
jaihindy-security-recommendation
branch
from
47c372d to
4c4508e
Compare
|
@jaihindy I really want to see the exact recipes. Like "open file foo and write bar there". Current text is stilll vague and imprecise. |
4 participants
This change adds documented security hardening recommendations for
production devices.
These recommendations were discussed and suggested to be added to
the README in:
#1244
The documentation is intended to provide clear guidance to downstream
integrators and deployers when preparing commercial or production
deployments. No functional or default behavior changes are introduced.