printk（）はセキュリティ上の問題を引き起こしますか？
関数printk()がLinuxでセキュリティの問題を引き起こすかどうかを自問しています。攻撃者がシステムにユーザーレベルのアクセス権を持っている場合、カーネルポインターへのアクセス権があれば、攻撃者の生活は楽になりますか？ printk()の使用は、システムで特権昇格の脆弱性を検索するときに何らかの方法で彼をサポートしますか？
Linuxカーネルの構成フラグとしてCONFIG_PRINTK=nを設定することにより、簡単に無効にすることができます。安全性の高いシステムで実行する必要がありますか？組み込みシステムはどうですか？ （私はシステムが後で非常に静かになることを知っています。）これについて誰かが何か推奨や経験がありますか？
関数printk（）がLinuxのセキュリティ問題であるかどうかを自問しています。
これは、サニタイズされていないポインタを出力する可能性のあるprintk()呼び出しがあるかどうかによって異なります。一般に、ポインタは kernel.kptr_restrict がゼロ以外のときにサニタイズされます。これは、ポインタの識別子が%pKであり、デフォルトでポインタをサニタイズするため機能します。ただし、たとえば、一部の値がポインターから計算されて出力されたり、タイプミスによって代わりに%pkが使用されたりして、誤ってポインターがリークしたりするという多くの状況があるようです。同じ消毒プロセスを経ます。これはこの関数に固有のものではなく、procやsysfsのように 仮想ファイルシステムで発生 になることもあります。これらの情報漏えいはまれではありません。
攻撃者がシステムにユーザーレベルのアクセス権を持っている場合、カーネルポインターへのアクセス権があれば、攻撃者の生活は楽になりますか？
はい、いいえ。攻撃者ができる最悪のこと* カーネルポインタを使用すると、カーネルのベースオフセットを検出してKASLRを壊すことができます。残念ながら、何度も何度も示されているように（ほとんどの場合Brad Spenglerによって）、KASLRはローカルの攻撃者に対して既に まったく役に立たない です。前述のようにinfoleaksを介して、またはほとんどのCPUアーキテクチャに対するさまざまなタイミング攻撃を介して倒すことができます。
Linuxカーネルの構成フラグとしてCONFIG_PRINTKを設定することで、簡単に無効にすることができます。安全性の高いシステムで実行する必要がありますか？
いいえ。より良いオプションがあります。印刷を無効にする代わりに、カーネルログバッファを読み取るための高い特権を必要とするようにします。これは、 kernel.dmesg_restrict を1に設定することで実行できます。これにより、サニタイズされず、syslogにリークするポインタから攻撃者が利用できないように保護します。そこに印刷されるかもしれない情報。
*これはストックカーネルにのみ当てはまります。独自のカーネルをコンパイルする場合、特に RANDSTRUCT を使用する場合、機密のカーネル関数の実際のオフセットを正確に特定できるため、攻撃者にとってポインタの知識が必要になります。