----- Original Message ----- > From: "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx> > To: "Hubert Kario" <hkario@xxxxxxxxxx> > Cc: security@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Thursday, 13 February, 2014 5:02:57 PM > Subject: Re: btrfs snapshots, rollbacks > > > > > On Feb 13, 2014, at 5:11 AM, Hubert Kario <hkario@xxxxxxxxxx> wrote: > > > As long as the old /bin and /usr/bin are not part of PATH, I'd say we've > > done our job. We can't protect the user from shooting himself in the foot > > in all cases. > > The snapshots aren't in PATH. However, the yum plugin would put them at > > /yum_<datetime>/bin /yum_<datetime>/usr/bin > > Snapper puts them in > > /.snapshots/<#>/snapshot/bin /.snapshots/<#>/snapshot/usr/bin > > I'm not sure what you mean by the user shooting himself - these locations > aren't up to the user with these tools. And installer behavior can limit > user choice as to where the snapshots can be placed. > > So, is the ability to hide snapshots in an unmounted portion of the (on-disk) > file system valuable from a security perspective? Or it it trivial? I would consider it trivial. > > The logs are a different matter, we should aim to preserve them. Dunno > > where > > journald is in this picture (binary log forward and backward > > compatibility). > > If by preserve you mean a single contiguous log location, then that implies > needing a subvolume for logs. For example: > > http://lists.freedesktop.org/archives/systemd-devel/2014-January/016253.html > > I have implemented this and it appears to work, although probably it should > be a log subvolume mounted at /var/log so that all logs can be kept > contiguous, not just the journal. Yes, that's what I was thinking about. If we're going to support update rollback through snapshots I think that /var/log should be kept separate in default install. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hkario@xxxxxxxxxx Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
