The exploit doesn't rely on the path being predictable though.
As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.
So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.
{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}
Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.
Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.
The exploit doesn't rely on the path being predictable though.
As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.
So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.
{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}
Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.
Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.
If the directory had a random name, the attacker could see that name and recreate it after /tmp is flushed.