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

[Mark Knecht]

On Fri, Mar 11, 2022 at 12:26 PM Rich Freeman <rich0@g.o> wrote:
>
> 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
>

Excellent info Rich. Thanks!

- Mark