----- Original Message ----- > From: "Till Maas" <opensource@xxxxxxxxx> > To: security@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Monday, 17 February, 2014 11:40:42 PM > Subject: Re: btrfs snapshots, rollbacks > > On Wed, Feb 12, 2014 at 07:16:34PM -0700, Chris Murphy wrote: > > > isn't mounted by default. The other question is whether there's a > > meaningful distinction between persistently mounting this snapshots > > subvolume, or only mounting it on demand when snapshots are about to > > be taken? And then when it's mounted, should the mount option be > > noexec or nosuid. > > If old snapshots are mounted, there are several possible security > implications: > > An old snapshot might contain > > - A world-readable confidential files thats permissions were fixed after > creating the snapshot, e.g. /etc/pki/tls/private/foo.key > > - A confidential file with too many ACLs that were fixed after creating > the snapshot > > - A confidential file with the bad selinux context allowing to be read > by an exploited daemon > > - A vulnerable suid binary > > - A vulnerable binary with capabilities > > - An executable with the wrong selinux context allowing an exploited > daemon to execute a binary that is not executable on the current > system > > - A device file with bad permissions/ACL/selinux context > > Therefore I guess it needs to be made sure that no unprivileged process > can access the contents of a mounted snapshot. Maybe the root directory > can be protected with strict permissions/ACLs and a selinux context that > does not allow anything else to access the contents. I agree. That is needed for /, especially on multi user systems. What about /home? Some of those issues apply to it too, problem is that making snapshots readable only for root user will make snapshots on /home nearly useless (if the admin needs to be involved to restore old version of a file he may just as well restore them from backup). I'm afraid we will have to relax the permissions of /home snapshots. -- 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
