lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez2gYFqifarkx3g8QP0aSzGswLpjxq_xPf4WiCPBn-GWAw@mail.gmail.com>
Date:   Sat, 30 Dec 2017 22:42:49 +0100
From:   Jann Horn <jannh@...gle.com>
To:     Dan Aloni <dan@...nelim.com>
Cc:     kernel list <linux-kernel@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [kernel-hardening] [PATCH 0/5] RFC: Public key encryption of
 dmesg by the kernel

On Sat, Dec 30, 2017 at 6:57 PM, Dan Aloni <dan@...nelim.com> wrote:
> From: Dan Aloni <dan@...nelim.com>
>
> Hi All,
>
> There has been a lot of progress in recent times regarding the removal
> of sensitive information from dmesg (pointers, etc.), so I figured - why
> not encrypt it all? However, I have not found any existing discussions
> or references regarding this technical direction.
>
> I am not sure that desktop and power users would like to have their
> kernel message encrypted, but there are scenarios such as in mobile
> devices, where only the developers, makers of devices, may actually
> benefit from access to kernel prints messages, and the users may be
> more protected from exploits.

What is the benefit of your approach compared to setting
dmesg_restrict=1 or something like that and letting userland decide
who should get access to raw dmesg output and in what form?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ