[systemd-devel] systemd shutdown vs ostree

[Colin Guthrie]

'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 13/09/13 16:33 did
gyre and gimble:
> On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
>>> On Thu, 12.09.13 23:31, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>>>
>>>>
>>>> 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
>>>>> On Thu, 12.09.13 21:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>>>>>
>>>>>>> So, as mentioned in the other thread, /usr should probably be on some
>>>>>>> "OS resource blacklist" or so, and not attempted to be shutdown.
>>>>>>>
>>>>>>> But unmounting /var during shutdown should actually work. The only thing
>>>>>>> that currently stops this from working cleanly is that journald is
>>>>>>> configured to stay around until the last moment, but currently has not
>>>>>>> interface to tell it to move its logging back to /run from /var. When we
>>>>>>> have that then the /var issue should go away for you, no?
>>>>>>
>>>>>> It would be quite nice to have an easy way for a compliant initrd to say
>>>>>> it can and will handle /var unmounting (perhaps by dropping a
>>>>>> var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 
>>>>>
>>>>> Yeah, such a drop-in should just work. Just add "DefaultDependencies=no"
>>>>> in there, and maybe instead "Before=local-fs.target", and you should be set.
>>>>
>>>> Nice, I'm sure dracut could implement that then.
>>>>
>>>>>> This will allow us to get persistent logs in which the initrd can
>>>>>> report it's progress until the last possible moment. This might help
>>>>>> debugging any problems in this particular link of the shutdown chain.
>>>>>
>>>>> I think the really late shutdown logs should more liekly end up in some
>>>>> EFI var and then flushed out on next boot or so...
>>>>
>>>> Nice plan. How would be able to "trust" that data tho'. Would it have to
>>>> be signed in some way? Or could it be marked somehow as unreliable data?
>>>> I'm not sure it really *matters* that much from a trust perspective as
>>>> it's use would likely be 99% debugging, but all the same it would be
>>>> nice if it were trustable.
>>>
>>> Trust?  I mean, if you managed to upload data into EFI vars you are so
>>> privileged you can fuck with us anyway, so not sure what you mean....
>>
>> Well I was originally thinking about other OS's etc. and knowing that
>> logs came from the right install, but then posed the question in a more
>> generic sense, in part due to the cryptographic guarantees given by FSS.
>> I just figured this was an interesting way in which someone could inject
>> false data at a point where you have zero way to know "what went on"
>> between the last shutdown and the current boot.
>>
>> If is to be inherently trusted based on machine id then fine - just
>> seems odd to put all the effort into FSS and then blindly inject data
>> (possibly even core dumps which will be analysed later) and not mark it
>> as potentially untrustworthy in some way.
>
> FSS doesn't protect against fake data, it only allows you to detect when
> data has been removed. So if I break into a machine with f-s-sealed logs,
> I am still able to log anything I want, but the messages about my break-in
> will be there, unless I remove some messages, in which case it will be visible
> that there are no messages since some point. The same guarantee holds for
> messages from pstore: you need root rights to write there. Even if there's
> a second OS on the machine, if you have root right in that *other* OS, you
> can write whatever you want to the logs in *this* OS, either through pstore
> or directly by mounting /var. So pstore doesn't really change anything here.

Hmm, yeah, I guess the point about writing invalid new data is probably
moot - as you say any $OTHEROS could do the same - assuming of course
the disk is not encrypted...

There would be some theoretical risk of a machine, with pstore and
encrypted disks where some attacker who has limited physical access
could plant a pstore "bomb" and then waits for the user to boot and
enter their encryption keys.... at which point the fake data is logged.
But I'm sure there are many more interesting things the attacker could
do if they were to have even limited physical access, so my argument is
almost certainly invalid in practically all circumstances :)

That said, if it's possible to somehow do the FSS of the pstore data and
verify it before incorporating it on the next boot, it seems like that
would be the most sensible approach by design (theoretically, in
principle etc. etc.) Practically useful... probably not much :)

Col











-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/