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.
Sincerely -- Mark Salyzyn
On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn <[email protected]> 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
On 03.02.2015 17:05, Mark Salyzyn wrote:
> Thanks for your response.
[...]
> 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.
OK. Thanks, for the additional information. Like I said, I am no
expert but juste felt an urge to ask a few questions.
:-)
--
Było mi bardzo miło. Twoje oczy lubią mnie
>Łukasz< i to mnie zgubi (c)SNL