Re: Where to report: root fails to edit other users file in sticky bit directory
I think the topic with the modes just applies when the file is actually
created, hence not existing yet.
However, aiming for a method to edit a file without O_CREAT, and voila:
-------
root@VM-Bullseye:~# cat testdir/testfile
143
root@VM-Bullseye:~# sed -i 's/1/5/' testdir/testfile
root@VM-Bullseye:~# cat testdir/testfile
543
root@VM-Bullseye:~# > testdir/testfile
-bash: testdir/testfile: Permission denied
-------
You nailed it! Now checking the kernel patch:
-------
root@VM-Bullseye:~# sysctl fs.protected_regular
fs.protected_regular = 2
root@VM-Bullseye:~# sysctl fs.protected_regular=0
fs.protected_regular = 0
root@VM-Bullseye:~# > testdir/testfile
root@VM-Bullseye:~# cat testdir/testfile
root@VM-Bullseye:~#
-------
Bingo!
Okay, so this is a security feature with the aim to prevent accidental
writes to a file owned by a potential attacker. I.e. since the directory
is world-writeable, an attacker can place a file that is knows is
written to by another user/victim. The victim actually aims to create a
new file (or write to it's own existing one), but now writes to the
prepared attackers file, which can then do whatever (s)he wants to do
with it as of ownership, to break the victims process or place different
information inside (then originally stored), like poisoning a cache and
such.
Yeah, somehow a thinkable scenario, although at least with systemd there
is PrivateTmp=true for this, and critical/sensitive information should
simply otherwise not be stored into /tmp root, a restricted sub
directory or /run or something like that. But the biggest problem is
that, while this effectively breaks sharing files (writeable) between
multiple users/processes, as many methods include O_CREAT, it is not
documented anywhere related to /tmp mount and sticky bit, so it is
mostly unexpected, isn't it? The results are errors which are hard to
debug, in my case it took me a full day to get to the essence of the
issue, while first I reviewed and re-tested and changed back and forth a
Python script (of some software I use, not my own).
And, root should IMO still be allowed to do it, as practically it can
anyway via chown. root can as well remove any file, regardless of sticky
bit, so this would be consistent.
Relevant package is then: procps
Ah, btw on Buster, by default it's disabled:
-------
2020-12-08 21:39:47 root@VM-Buster:~# sysctl fs.protected_regular
fs.protected_regular = 0
-------
Many thanks for looking deeper at O_CREAT guys, I likely wouldn't have
searched into this direction :)!
Best regards and stay healthy,
Micha
Reply to: