Re: [gentoo-user] Re: Root can't write to files owned by others?

[Rich Freeman]

On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht <markknecht@×××××.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