Re: [PATCH v4 4/5] pstore: add pmsg

[Kees Cook <keescook@chromium.org>]

On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn <salyzyn@android.com> wrote:
> Thanks for your response.
>
> On 01/30/2015 12:57 PM, Lukasz Stelmach wrote:
>>
>> On 28.01.2015 18:28, Mark Salyzyn wrote:
>>>
>>> - Precious little user-space content goes to kmsg (otherwise you
>>> can ask why is there a syslogd?), there is a reason for this, user
>>> space is notorious for containing Personal Identifiable Information
>>> whereas kernel information does not.
>>
>> Sure it does too: MAC addresses, UUIDs, serial numbers. With mobile
>> devices these are actually PII.
>
> :-)
>
> Names, Passwords, credit card number, addresses. Personal Identifiable
> Information, lawsuits are never lodged against MAC addresses UUIDs or serial
> numbers.
>>>
>>> - pmsg0 can take a lot of content (with a ramoops backend) and
>>> will not disrupt/DOS the kernel logs.
>>
>> Documentation/ramoops.txt says it is for logging kernel oopses
>> and panics not user logs.
>
> I probably should have changed the ramoops.txt content with the addition of
> pmsg :-)
>>
>>
>> - /dev/pmsg0 write is atomic
>> devkmsg_write + vprintk_emit are atomic too.
>
> Hmmm, I managed to get content corrupted
>>>
>>> - /dev/pmsg0 is write only, there is no access to the live content
>>> _unless_ there is a reboot.
>>
>> Why do you consider this an advantage?
>
> It is more serendipity than design, once this feature was highlighted, it
> became a must-have for the security concerns. The current boot instance
> contains an environment of files, programs and state information that
> combined would be useful for cracking a large amount of PII. Once a kernel
> panics what remains is a trace of user-space activities that can be
> correlated with kernel activities in order to replay or triage what lead up
> to the kernel panic. Yet crippled enough to not be as useful as a vector.
>>>
>>> - Personal identification which abounds in user space could be placed
>>> into /dev/pmsg0, and there is no way except a reboot in order to
>>> extract the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be
>>> deleted, or heavily MAC and DAC controlled to enforce protection
>>> (doing so to kmsg would be unlivable)
>>
>> Read access to /dev/kmsg can be limited too.
>
> When you delete /sys/fs/pstore/pmsg-ramoops-0 after moving it to secure
> storage, it is gone. Same is separately true for
> /sys/fs/pstore/console-ramoops-0, so yes, similar characteristics. The issue
> is separation. The issue is also no ability to read the live content of the
> user space data until it becomes relevant (kernel panic triage).
>>
>>
>> I think that the goals you present can be met with less code.
>> You could try adding support for multiple /dev/kmsg instances
>> for example. How about that?
>
> Not a bad idea. But with multiple kmsg instances, you also get to add code
> in pstore to divide it up along with a device tree that decides how much
> storage is provided for each instance. I would wager a desire will be
> expressed to make sure the live co There is a vacuum.ntent be accessible
> with a netlink socket and  a new flag in dmesg which would be counter to our
> security concerns.
>
> pstore is all about persistence. kmsg is not, until pstore supports it. A
> user-space persistent storehouse felt appropriate to support at the bottom
> layer.
>

FWIW, I prefer keeping "pmsg" separate from "kmsg". They do feel
similar, but given the persistence backing, I think it justifies the
separation. I'm not sure it's right to change the semantics of kmsg.

-Kees


> Sincerely -- Mark Salyzyn



-- 
Kees Cook
Chrome OS Security