Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a
directory that is setgid and owned by a different gid than current's

fsgid, you

end up with an SGID executable that is owned by the directory's GID.  This

is

a Bad Thing (tm).  Exploiting this is nontrivial because most ways of

creating a

new file create an empty file and empty executables aren't particularly
interesting, but this is nevertheless quite dangerous.

Harden against this type of attack by detecting this particular corner

case

(unprivileged program creates SGID executable inode in SGID directory
owned by a different GID) and clearing the new inode's SGID bit.

Nasty.

I'd love to see a test for this in xfstests and/or pjdfstests...

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>