Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 12:26 PM Rich Freeman wrote: > > On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht 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
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 1:23 PM Mark Knecht 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
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 10:06 AM Nikos Chantziaras wrote: > > 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? > > 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
[gentoo-user] Re: Root can't write to files owned by others?
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?
RE: [gentoo-user] Re: Root can't write to files owned by others?
>-Original Message- >From: Neil Bothwick >Sent: Friday, March 11, 2022 6:59 AM >To: gentoo-user@lists.gentoo.org >Subject: Re: [gentoo-user] Re: Root can't write to files owned by others? > >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. > I was just looking at the patch. In at least one of its modes I think it's specifically looking for the sticky bit on the directory. I didn't think to pay attention to what the new default setting ends up doing for which specific mode it goes with. LMP
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Fri, Mar 11, 2022 at 7:59 AM Neil Bothwick wrote: > > 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? - Mark
Re: [gentoo-user] Re: Root can't write to files owned by others?
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. pgpLaeAibxRPa.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Root can't write to files owned by others?
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
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Friday, 11 March 2022 03:04:47 GMT Nikos Chantziaras wrote: > 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. ~ $ 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. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Root can't write to files owned by others?
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.
Re: [gentoo-user] Re: Root can't write to files owned by others?
Here is the kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5 for this: Am Donnerstag, 10. März 2022, 19:44:46 CET schrieb Michael: > > Just checked and it is so, on openrc: > > ~ # uname -r > 5.15.26-gentoo > ~ # sysctl -a | grep fs.protected_regular > fs.protected_regular = 1
Re: [gentoo-user] Re: Root can't write to files owned by others?
On Thursday, 10 March 2022 17:59:00 GMT Laurence Perkins wrote: > >-Original Message- > >From: Dr Rainer Woitok > >Sent: Thursday, March 10, 2022 9:51 AM > >To: gentoo-user@lists.gentoo.org; Nikos Chantziaras > >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 signature.asc Description: This is a digitally signed message part.
RE: [gentoo-user] Re: Root can't write to files owned by others?
> > >-Original Message- >From: Dr Rainer Woitok >Sent: Thursday, March 10, 2022 9:51 AM >To: gentoo-user@lists.gentoo.org; Nikos Chantziaras >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
[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
Re: [gentoo-user] Re: Root can't write to files owned by others?
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
RE: [gentoo-user] Re: Root can't write to files owned by others?
>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 > > And they chose to have systemd set that instead of putting it in sysctl.conf or the default kernel settings where it belongs? Good grief! I guess if you're going to use systemd you need to subscribe to the Fedora mailing lists so you get at least a little notice before they break things. LMP
Re: [gentoo-user] Re: Root can't write to files owned by others?
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
[gentoo-user] Re: Root can't write to files owned by others?
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.
[gentoo-user] Re: Root can't write to files owned by others?
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
[gentoo-user] Re: Root can't write to files owned by others?
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
