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

[Dr Rainer Woitok]

Greetings,

until recently my system behaves sort of strangely:

$ touch /tmp/file
$ ls -l /tmp/file
-rw------- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
$ echo x | sudo tee /tmp/file
Password:
tee: /tmp/file: Permission denied
x
$ chmod a+w /tmp/file
$ ls -l /tmp/file
-rw--w--w- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
$ echo x | sudo tee /tmp/file
tee: /tmp/file: Permission denied
x
$

Since when can't root write to files it doesn't own? And not even, if
the file has write permission for everybody?

This worked as long as I can think of. My last routine upgrade install-
ed new kernel package "sys-kernel/gentoo-sources-5.15.26", so I built
the new kernel and booted from it. May this be the reason?

When I'll have time to reboot, I'll test the above commands on my old
kernel, 5.15.19. But perhaps there's another reason?

Slightly puzzled
Rainer

[Jack]

Just a gues, but try something like 'sudo -c "echo x | tee /tmp/file"'
or just su first and then do the echo and tee. I think perhaps the
permission error is not for root writing to /tmp/file but for the echo
x trying to write to a tee owned by root.

[Peter Böhm]

Rainer,

using sudo does not makes you a root user. To become a root user you have to
switch with "su -" (and login with root password).

Sudo has its own configuration file. If you can do something with sudo on other
systems means there is a different configuration for sudo.

Check "man sudo"

Cheers,
Peter

[Nikos Chantziaras]

On 09/03/2022 20:28, Dr Rainer Woitok wrote:
> until recently my system behaves sort of strangely:
>

> $ echo x | sudo tee /tmp/file
> Password:
> tee: /tmp/file: Permission denied

> [...]

>
> Since when can't root write to files it doesn't own? And not even, if
> the file has write permission for everybody?

This is normal, at least when using systemd. To disable this behavior,
you have to set:

sysctl fs.protected_regular=0

But you should know what this means when it comes to security. See:

https://www.spinics.net/lists/fedora-devel/msg252452.html

[Dr Rainer Woitok]

Greetings,

On Wednesday, 2022-03-09 19:28:49 +0100, I myself wrote:

> ...

> $ touch /tmp/file
> $ ls -l /tmp/file
> -rw------- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
> $ echo x | sudo tee /tmp/file
> Password:
> tee: /tmp/file: Permission denied
> x

> $ ...
> $

Big thanks to all kind people making suggestions. But up to now nothing
helped.

> ...

> When I'll have time to reboot, I'll test the above commands on my old
> kernel, 5.15.19.

Surprisingly, this did in fact help. My rig is back to normal behav-
iour! :-O

For what it's worth, these were the only kernel configuration changes
when building kernel 5.15.26 while running kernel 5.15.19 using

# make olddefconfig

-CONFIG_CC_VERSION_TEXT="gcc (Gentoo 11.2.0 p1) 11.2.0"
+CONFIG_CC_VERSION_TEXT="gcc (Gentoo 11.2.1_p20220115 p4) 11.2.1 20220115"
-CONFIG_GCC_VERSION=110200
+CONFIG_GCC_VERSION=110201
+# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set

So again: what am I missing? For the time being I'll stay with this old
kernel version, even though it's no longer available upstream.

Sincerely,
Rainer

[Nikos Chantziaras]

On 10/03/2022 11:55, Dr Rainer Woitok wrote:
> Big thanks to all kind people making suggestions. But up to now nothing
> helped.

Are you sure that:

sysctl fs.protected_regular=0

does not help? I can reproduce it here on my system with kernel 5.15.27,
and setting that sysctl to 0 fixes it immediately.

[Björn Fischer]

Hello Rainer,

> Big thanks to all kind people making suggestions. But up to now nothing
> helped.

on my rig I can fully reproduce Nikos' statement.

Additionally, on 5.15.16 "fs.protected_regular" defaults to "0" while on
5.15.27 it defaults to "1".

Cheers,

Björn

[Grant Taylor]

On 3/9/22 11:50 PM, Nikos Chantziaras wrote:
> This is normal, at least when using systemd.

How is this a /systemd/ thing?

Is it because systemd is enabling a /kernel/ thing that probably is
otherwise un(der)used?

I ask as someone who disliked systemd as many others do. But I fail to
see how this is systemd's fault.

> To disable this behavior, you have to set:
>
>   sysctl fs.protected_regular=0
>
> But you should know what this means when it comes to security. See:
>
> https://www.spinics.net/lists/fedora-devel/msg252452.html

I read that message, but no messages linked therefrom, and don't see any
security gotchas about disabling (setting to 0) fs.protected_*

I see some value in a tunable to protect against writing to files of
different type in the guise of protecting against writing somewhere that
you probably want to not write. Sort of like shell redirection ">"
protection for clobbering existing files where you likely meant to
append ">>" to them.

But I am ignorant as to how this is a /systemd/ thing.



--
Grant. . . .
unix || die

[Dr Rainer Woitok]

Nikos,

On Thursday, 2022-03-10 12:21:36 +0200, you wrote:

> ...

> Are you sure that:
>
> sysctl fs.protected_regular=0
>
> does not help? I can reproduce it here on my system with kernel 5.15.27,
> and setting that sysctl to 0 fixes it immediately.

No, I'm not at all sure. Since you mentioned in your first mail that
this is normal when using "systemd", I did not pursue this route any
further, because I'm using "openrc".

I'll search the web for "fs.protected_regular" to get a feeling for the
consequences and then perhaps set this when I'll again boot kernel vers-
ion 5.15.26.

Thanks for being persistent :-)

Sincerely,
Rainer

[Michael]

On Thursday, 10 March 2022 17:59:00 GMT Laurence Perkins wrote:

> Basically the idea is to keep other users from being able to trick root into
> writing sensitive data to something they control. It's a "systemd thing"
> because, apparently, the systemd developers decided to have systemd enable
> it instead of leaving it in the bailiwick of the distros' configurations.
> But if the default setting changed in a later kernel as well, that would
> potentially affect everyone, so a quick check of what it's set to wouldn't
> be amiss.
>
> LMP

Just checked and it is so, on openrc:

~ # uname -r
5.15.26-gentoo
~ # sysctl -a | grep fs.protected_regular
fs.protected_regular = 1

[Peter Böhm]

Here is the kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/
torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

for this:

[Nikos Chantziaras]

On 10/03/2022 20:44, Michael wrote:
> ~ # sysctl -a | grep fs.protected_regular
> fs.protected_regular = 1

To check the current value of a setting, you can just run:

sysctl fs.protected_regular

No grep or root needed.

[Michael]

~ $ sysctl fs.protected_regular
sysctl: permission denied on key 'fs.protected_regular'

You're right about grep, but not about root. Anyway, I can confirm on kernel
5.15.23 fs.protected_regular is set to 0, while on 5.15.26 is it flipped to 1.

[Dr Rainer Woitok]

Aho,

On Friday, 2022-03-11 10:17:13 +0100, you wrote:

> ...
> I think Rainer's problem is the nosuid mount flag on his /tmp
>
> $ mount | grep \/tmp
> tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,size=3212160k,inode64)
>
> So if he would run the command against a file not located in /tmp I
> think it would work, at least it does for me as it's only /tmp that has
> nosuid.

No. My "/tmp/" directory is not mounted at all, it is just a genuine
directory in "/". And that root CAN overwrite a file it doesn't own in
other directories, is due to most directories not having the sticky bit
set (which is a (wanted) particularity of "/tmp/" and "/var/tmp/", in
that it prevents normal users from (re)moving other people's files):

$ ls -ld / /tmp /var/tmp
drwxr-xr-x 21 root root 4096 2021-01-25 12:17 /
drwxrwxrwt 10 root root 69632 2022-03-11 12:16 /tmp
drwxrwxrwt 3 root root 4096 2022-03-10 10:23 /var/tmp
$
^
This "t" indicates a set sticky bit.

Sincerely,
Rainer

[Neil Bothwick]

On Fri, 11 Mar 2022 12:38:48 +0100, Dr Rainer Woitok wrote:

> No. My "/tmp/" directory is not mounted at all, it is just a genuine
> directory in "/". And that root CAN overwrite a file it doesn't own in
> other directories, is due to most directories not having the sticky bit
> set (which is a (wanted) particularity of "/tmp/" and "/var/tmp/", in
> that it prevents normal users from (re)moving other people's files):

It's not the sticky bit per se from what I've read, but the new default
prevents root from overwriting a file if the file and the directory
containing it have different owners. In most cases, the file has the same
directory as the owner so this does not happen, but the sticky bit allows
users that don't own the directory to create files in it.


--
Neil Bothwick

Assassins do it from behind.

[Mark Knecht]

Is this related to the 'dirty pipe' vulnerability that has been in the
news of late and has gotten patched in most distros in the last few
days?

- Mark

[Nikos Chantziaras]

On 11/03/2022 17:06, Mark Knecht wrote:
> Is this related to the 'dirty pipe' vulnerability that has been in the
> news of late and has gotten patched in most distros in the last few
> days?

In one of the discussions about the patch, it was mentioned that "a
couple of CVEs would have never happened" if this had been the default
to begin with. So, probably yes?

[Dr Rainer Woitok]

Greetings,

On Wednesday, 2022-03-09 19:28:49 +0100, I myself wrote:

> ...

> until recently my system behaves sort of strangely:
>
> $ touch /tmp/file
> $ ls -l /tmp/file
> -rw------- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
> $ echo x | sudo tee /tmp/file
> Password:
> tee: /tmp/file: Permission denied
> x
> $ chmod a+w /tmp/file
> $ ls -l /tmp/file
> -rw--w--w- 1 rainer rainer 0 2022-03-09 19:06 /tmp/file
> $ echo x | sudo tee /tmp/file
> tee: /tmp/file: Permission denied
> x
> $
>
> Since when can't root write to files it doesn't own? And not even, if
> the file has write permission for everybody?

Turns out it's not a bug but a feature, more precisely a security feat-
ure. Its purpose is to prevent an unprivileged local user from luring
user "root" into writing possibly sensitive information to an already
existing file owned by and thus accessible to the local attacker.

This protection feature was introduced as an option deactivated by def-
ault way back in some 4.* kernel, and somewhere between kernels 5.15.19
and 5.15.26 the default was changed to on.

If you want or have to, you can again disable this feature at runtime
using

# sysctl fs.protected_regular=0

or permanently from the next boot onwards via

# echo fs.protected_regular = 0 >> /etc/sysctl.d/local.conf

Personally, I've decided to again boot kernel 5.15.26, to leave the new
default setting (even on my laptop), and to adapt my script which had
problems with this new behaviour accordingly.

Your milage may vary.

Sincerely,
Rainer

[Mark Knecht]

My Kubuntu system is set to '1' but Ubuntu released a patchset for 15
CVEs including the dirty pipe and I didn't even know about this
feature before this news so I have no idea if this was just changed
here but I suspect it was. I'm on a much older kernel than most of you
guys.

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.

Thanks for the response,
Mark

[Rich Freeman]

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

[Mark Knecht]

Excellent info Rich. Thanks!

- Mark