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 ([email protected]) 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 ([email protected]) 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.
Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
