> 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 from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
