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. Fedora is already in a good position to go either way, because rootfs is in a subvolume called "root". The name can be different, but the fact it will be in a separate subvolume and not at the top level of the Btrfs file system is immutable. Conversely, other distros are putting rootfs at the top level of the Btrfs file system as if it were any other file system, so there's no flexibility. Now if we can get /boot on Btrfs supported… Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
