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?
...
$ 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
$ ...
$
...
When I'll have time to reboot, I'll test the above commands on my old kernel, 5.15.19.
Big thanks to all kind people making suggestions. But up to now nothing helped.
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.
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
-----Original Message-----
From: Dr Rainer Woitok <rainer.woitok@gmail.com>
Sent: Thursday, March 10, 2022 9:51 AM
To: gentoo-user@lists.gentoo.org; Nikos Chantziaras <realnc@gmail.com> >Subject: [gentoo-user] Re: Root can't write to files owned by others?
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
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
~ # sysctl -a | grep fs.protected_regular
fs.protected_regular = 1
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.
...
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):
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.
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?
...
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?
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?
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.
On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht <markknecht@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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 302 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 98:42:22 |
| Calls: | 6,767 |
| Calls today: | 5 |
| Files: | 12,295 |
| Messages: | 5,376,396 |
| Posted today: | 1 |