----- Original Message ----- > From: "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx> > To: security@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Thursday, 13 February, 2014 7:13:22 PM > Subject: Re: btrfs snapshots, rollbacks > > > On Feb 13, 2014, at 11:05 AM, Miloslav Trmač <mitr@xxxxxxxx> wrote: > > > On Thu, Feb 13, 2014 at 3:16 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > > wrote: > > How significant is the risk of stale binaries being persistently available > > in the normal file system hierarchy? > > Depending on the vulnerability being fixed, up to "critical". > > > > Should something be done to either make sure they aren't persistently > > available (make sure they aren't available in the mounted file system > > hierarchy) > > Yes. > > > > and if they're mounted should noexec or nosuid be used? > > Probably; A possible alternative would be to mount them into /$snapshots, > > where $snaphosts is 0700 root-only (and protected by SELinux to only an > > unconfined administrator) - but without SELinux a root-owned process with > > no capabilities would still be able to access the files. > > > > Because the snapshot is located within a mounted subvolume, it makes the > > snapshot's stale binaries persistently available. So restating the earlier > > question, is this a security risk, how significant is it, and is it worth > > changing the behavior? > > > > Yes, very, and yes. (The risk is that there is a security vulnerability in > > a setuid-root program, and making the vulnerable application runnable by > > unprivileged users keeps the vulnerability exploitable. It doesn't matter > > whether the file is in PATH, or where exactly it is located, as long any > > process that doesn't have the privileges of an unconfined system > > administrator can access it.) > > > > Interesting :-) two opposite opinions on this. Not really, I was thinking from a desktop system perspective. It's completely different matter on a server. -- 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
