[systemd-devel] systemd shutdown vs ostree

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 13, 2013 at 04:48:37PM +0100, Colin Guthrie wrote:
> '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 :)
I think we need a new _TRANSPORT=pstore tag.

We currently don't do any verificiation for normal logs either: it is up
to the reader to notice that fields don't match. But it would be nice to
have an external tool like this.

Zbyszek