On Fri, Mar 11, 2022 at 12:26 PM Rich Freeman <ri...@gentoo.org> wrote: > > 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 >
Excellent info Rich. Thanks! - Mark
