On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht <markkne...@gmail.com> wrote: > > To me the overriding idea of not letting any user, including root, > mess around in a pipe makes logical sense, but as the OP has showed I > guess there were valid uses for this feature pre-patch, and it seems > that a user can override the feature by setting some bits if they need > to and really think they know what they are doing.
There has been a long history of exploits on Unix involving places like /tmp because it is so easy for different users to step on each other's toes, possibly deliberately. The sorts of things that can go wrong are usually not intuitive, though anybody creating files in a world/group-writable location really should be aware of them. This is also the reason why you should never have "." in your path. Usually attacks work by predicting some file that a root-controlled process is about to create, and then creating it before the process does, so that the process ends up opening an existing file that you control instead of a new file that it controls. Programmers sometimes anticipate issues and create their own safeguards, but fail to understand race conditions so there can be a time gap between after the sanity checks are run and when the file is created. There is also a principle in security in general that suggests that any situation where data can pass between two different privilege levels needs to be safeguarded by default. I believe there are operating system models (probably including SELinux) that block such flows/transitions by default, and force programmers to explicitly define them so that they can't happen inadvertently. Basically if a non-privileged process can only interact with a privileged process via very tightly controlled APIs then it is much easier to secure the process, even if a programmer can't anticipate all the ways that such an interaction might occur. In this particular case it just sounds like you need to open the file without using O_CREAT if you intend to open an existing process owned by another user, and if you intend to create a new file then you can use O_CREAT and if the system call fails that is a feature and not a bug. This safeguard forces the programmer to explicitly communicate to the kernel if it intended to open an existing file owned by a non-root user, vs getting tricked into it when it intended to create a new one. You can catch the failure and try again with a different name if you had wanted to create a temp file. -- Rich
