Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > No, it just means gparted has a security bug, because the permissions > did work as the user intended before gparted changed them without the > users knowledge, and they would have worked if gparted wasn't insecurely > exposing the files. Claiming that the side effect of keeping the fs either unmounted or mounted somewhere users can't see is part of the permissions is like claiming that keeping power from reaching the computer is part of the security system. I mean, without the ability to power on the computer, people can't access the files, so by your logic, if I plug the computer in then I'm the problem. Any setup that relies on directory traversal to prevent people from reaching files that they otherwise are given access to is very fragile and badly set up. If an admin later builds a chroot environment for isntance, and sets up some bind mounts, they can inadvertently give access to the wrong users because they now can see the files that have poorly configured permissions. It's just not smart to do things that way. > The reason why your logic doesn't work is that you claim *every* debian > root fs has the wrong permissions, because some directories might be > world-writable (such as /tmp) which might not be what the user > intended It isn't /tmp that is wrong, but whatever files you are storing in the btrfs volume and have left set to 777. Don't do that. > by not having the fs mounted in an insecure location (and thus allowing a > DoS attack). It would also mean filesystems such as fat, without intrinsic > permissions, would somehow have "wrong" permissions. That's why fat has mount options to set the permissions on the fs globally. >> When gparted mounts it somewhere that isn't traverse proof, yes, that >> does allow access where it was not previously, but that's really only >> exposing the underlying bug that was always there: that the permissions >> on the files are too loose. > > Well, I have asked you for the source of this claim, but you haven't given > one - and I claim you just made it up, because I can't believe you have a > source. Source? The source is the givens of the scenario we are discussing -- a file or files in a filesystem with mode 777 so that everyone can access it, but mounted in a directory that is traverse restricted. That is de facto too loose. If you are just going to make an appeal to authority fallacy in continued attempts to semantically redefine loose to tight and wrong right, then this is just a waste of time.
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 02:52:59PM -0500, Phillip Susi wrote: > > You keep making this false claim, but that doesn't lend it more > > credence. POSIX permissions work the way they work, and if you think some > > combination of permissions are wrong, what are the rules to determine > > right and wrong and what is your source for this repeated statement? > > Simple... right doesn't allow access to the people you don't want to > have it. Wrong permissions do allow access to those you don't intend to > have it. Working around that by other means ( to deny access to the > entire filesystem ) does not change the fact that the permissions on the > file are not configured correctly to carry out your intent. No, it just means gparted has a security bug, because the permissions did work as the user intended before gparted changed them without the users knowledge, and they would have worked if gparted wasn't insecurely exposing the files. gparted *changed* the effective permissions of files by mounting the fs in an insecure location. The reason why your logic doesn't work is that you claim *every* debian root fs has the wrong permissions, because some directories might be world-writable (such as /tmp) which might not be what the user intended by not having the fs mounted in an insecure location (and thus allowing a DoS attack). It would also mean filesystems such as fat, without intrinsic permissions, would somehow have "wrong" permissions. I really don't understand why it is so difficult to simply accept that gparted has a security bug. It happens. It should be fixed. It's not the most dangerous security bug, after all... Fact is, gparted exposes files because it changes effective permissions. Whether you all these permissions right or wrong, green or blue, ethical or satanistic doesn't have any influence on this fact - all these classifications are your own personal opinions and don't have any merit in objectively analying this bug. > > Ah, maybe I see where you are copming from - gparted changes effective > > permissions, so they are wrong. > > No, I didn't say anything about gparted. Well, then you missed the topic - this bug report is about discussing a specific gparted security bug, if you want to discuss something else, you can try to engange me somewhere else or privately. > When gparted mounts it somewhere that isn't traverse proof, yes, that > does allow access where it was not previously, but that's really only > exposing the underlying bug that was always there: that the permissions > on the files are too loose. Well, I have asked you for the source of this claim, but you haven't given one - and I claim you just made it up, because I can't believe you have a source. If you could point out where, in the SuS, it says which permissions are wrong and which are right, then you might have something to discuss. But SuS only documents how permissions work, how they effectively apply, and according to the cold hard facts, gparted exposes files that weren't exposed before. It's that simple. Anyways, I am out of here, have a good one! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > Maybe it helps when you realise thta chown can also modify a file... Only root can do that. In any case, I was ceeding the point that it is essentially the same thing. > You yourself mentioned some - in any case, does this lead somewhere? I was just curious if there were some that I didn't know about. >> In both cases the permissions on the file itself are wrong, > > You keep making this false claim, but that doesn't lend it more > credence. POSIX permissions work the way they work, and if you think some > combination of permissions are wrong, what are the rules to determine > right and wrong and what is your source for this repeated statement? Simple... right doesn't allow access to the people you don't want to have it. Wrong permissions do allow access to those you don't intend to have it. Working around that by other means ( to deny access to the entire filesystem ) does not change the fact that the permissions on the file are not configured correctly to carry out your intent. >> >> The permissions allow access that you do not wish it to. Ipso facto, >> the permissions are incorrect. > > Ah, maybe I see where you are copming from - gparted changes effective > permissions, so they are wrong. No, I didn't say anything about gparted. When gparted mounts it somewhere that isn't traverse proof, yes, that does allow access where it was not previously, but that's really only exposing the underlying bug that was always there: that the permissions on the files are too loose. If you are running an unpatched kernel that is vulnerable to a remote exploit and aren't connected to the network, then you don't have to worry about it, but if I plug in an Ethernet cable, it doesn't mean that the breach of security is my fault.
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 10:11:13AM -0500, Phillip Susi wrote: > > doesn't matter how exactly I change a file, as long as I can change it > > when I shouldn't be, it is a security bug. > > True, you can delete the file and replace it, but then it is now owned > by you instead of the original owner. It's a fair argument that it > amounts mostly to the same thing. Maybe it helps when you realise thta chown can also modify a file... > > No, there are other possibilities, but that is one way, yes. > > Other possibilities like what? You yourself mentioned some - in any case, does this lead somewhere? > >> looser permissions, and that amounts to the same thing as just not > >> keeping it mounted most of the time. > > > > No, these are very different things. > > How so? If you can't see how not mounting a filesystem and having ti accessible by various means are very different, I am afraid I don't see how I can explain it to you. > In both cases the permissions on the file itself are wrong, You keep making this false claim, but that doesn't lend it more credence. POSIX permissions work the way they work, and if you think some combination of permissions are wrong, what are the rules to determine right and wrong and what is your source for this repeated statement? It seems to me your claim of "wrongess" is a value statement only - do you have any objective arguments, too? > > Your question is loaded, because it presumes that the correct permissions > > are somehow incorrect (a contradiction that any answer would have to > > accept, which makes it impossible to answer your question). That is > > The permissions allow access that you do not wish it to. Ipso facto, > the permissions are incorrect. Ah, maybe I see where you are copming from - gparted changes effective permissions, so they are wrong. Well, congratulations, that's exactly why this is a security bug in gparted - the user doesn't wish file access and configures the permissions accordingly, but gparted circumvents this user configuration, and this is unexpected, and incorrect behaviour. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > When you recreate a file with different contents you have modified it. > Anything else is weird word twisting, and not useful in this context - it > doesn't matter how exactly I change a file, as long as I can change it > when I shouldn't be, it is a security bug. True, you can delete the file and replace it, but then it is now owned by you instead of the original owner. It's a fair argument that it amounts mostly to the same thing. > No, there are other possibilities, but that is one way, yes. Other possibilities like what? >> looser permissions, and that amounts to the same thing as just not >> keeping it mounted most of the time. > > No, these are very different things. How so? In both cases the permissions on the file itself are wrong, and you are relying other mechanisms to stop access before it gets to checking the wrong permissions. > Your question is loaded, because it presumes that the correct permissions > are somehow incorrect (a contradiction that any answer would have to > accept, which makes it impossible to answer your question). That is > not The permissions allow access that you do not wish it to. Ipso facto, the permissions are incorrect.
Bug#916260: gparted mounts partition without protection
On Tue, Feb 11, 2020 at 09:18:30AM -0500, Phillip Susi wrote: > > The effective permissions for a path depend on more than just the > > permissions of the file it refers to. For example, a root-only readable > > file can still be changed by normal users if the directory is writable for > > them. > > No, it can't. Yes it can. > If the directory is writable, then the user can modify the directory, > i.e. to rm the file, but they can't modify the file itself. When you recreate a file with different contents you have modified it. Anything else is weird word twisting, and not useful in this context - it doesn't matter how exactly I change a file, as long as I can change it when I shouldn't be, it is a security bug. > > effective permissions in ways not expected by the user, by mounting it in > > an insecure location. > > The only way it can change the effective permissions are if you normally > have it mounted in a directory that uses the traverse/execute permission > to restrict who can traverse it with the files inside otherwise having No, there are other possibilities, but that is one way, yes. > looser permissions, and that amounts to the same thing as just not > keeping it mounted most of the time. No, these are very different things. > filesystem namespace so that it is only mounted to the one user and not > visable to the rest of the system. Either way, it begs the question: > why not just set the permissions correctly instead? Your question is loaded, because it presumes that the correct permissions are somehow incorrect (a contradiction that any answer would have to accept, which makes it impossible to answer your question). That is not so, of course, which I have already pointed out (wehich begs the question why you repeat this falsehood :). > Come to think of it, maybe using filesystem namespaces would be a better > idea than chmod()ing the /tmp mount point ( and then creating another > subdirectory in which to actually mount the fs ). A less portable, more complicated, but altogether valid solution, yes. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > It happens also for filesystems with correct permissions - maybe this is > the point you have problems with? > > The effective permissions for a path depend on more than just the > permissions of the file it refers to. For example, a root-only readable > file can still be changed by normal users if the directory is writable for > them. No, it can't. If the directory is writable, then the user can modify the directory, i.e. to rm the file, but they can't modify the file itself. > That means the whole access path needs to be taken into account, and > this is why the security issue is in gparted, because gparted changes > effective permissions in ways not expected by the user, by mounting it in > an insecure location. The only way it can change the effective permissions are if you normally have it mounted in a directory that uses the traverse/execute permission to restrict who can traverse it with the files inside otherwise having looser permissions, and that amounts to the same thing as just not keeping it mounted most of the time. Or I suppose you could use a filesystem namespace so that it is only mounted to the one user and not visable to the rest of the system. Either way, it begs the question: why not just set the permissions correctly instead? Come to think of it, maybe using filesystem namespaces would be a better idea than chmod()ing the /tmp mount point ( and then creating another subdirectory in which to actually mount the fs ).
Bug#916260: gparted mounts partition without protection
On Mon, Feb 03, 2020 at 01:07:55PM -0500, Phillip Susi wrote: > > 3. Now *another user* on the same machine can access that file system, > >which I unwittingly mounted and exposed. > > I get it, I just don't understand why you would have a filesystem around > whose internal permissions were not already set up correctly but instead > you relied on not mounting it to protect it. It happens also for filesystems with correct permissions - maybe this is the point you have problems with? The effective permissions for a path depend on more than just the permissions of the file it refers to. For example, a root-only readable file can still be changed by normal users if the directory is writable for them. That means the whole access path needs to be taken into account, and this is why the security issue is in gparted, because gparted changes effective permissions in ways not expected by the user, by mounting it in an insecure location. Or in other wors, gparted can make files accessible that weren't accessible before, without the user reasonably expecting this (as the user expectation is that gparted doesn't widen effective permissions). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
Nicolas Braud-Santoni writes: > The scenario at play is the following: > > 1. I am a user with some level of administrative privileges, and run gparted. > 2. I resize a partition (btrfs, in Marc's initial report), >causing it to be mounted under /tmp, with a mountpoint that's chmod 0777. > 3. Now *another user* on the same machine can access that file system, >which I unwittingly mounted and exposed. I get it, I just don't understand why you would have a filesystem around whose internal permissions were not already set up correctly but instead you relied on not mounting it to protect it. > I agree with Marc that the simplest way to negate the issue would be > for gparted to make a private, temporary directory (chmod 0700) and put > all its temporary files and mountpoints there, so they cannot be accidentally > exposed to other users. Yea, I suppose it's a simple enough change.
Bug#916260: gparted mounts partition without protection
Hi Phillip, On Thu, Dec 13, 2018 at 09:02:24AM -0500, Phillip Susi wrote: > On 12/12/2018 11:59 PM, Marc Lehmann wrote: > > As you say, there are several ways, some where the user can choose to > > make the files accessible and some where she can choose to not make them > > available. > > I'm not sure what you mean by this. The scenario at play is the following: 1. I am a user with some level of administrative privileges, and run gparted. 2. I resize a partition (btrfs, in Marc's initial report), causing it to be mounted under /tmp, with a mountpoint that's chmod 0777. 3. Now *another user* on the same machine can access that file system, which I unwittingly mounted and exposed. I agree with Marc that the simplest way to negate the issue would be for gparted to make a private, temporary directory (chmod 0700) and put all its temporary files and mountpoints there, so they cannot be accidentally exposed to other users. Best, nicoo signature.asc Description: PGP signature
Bug#916260: gparted mounts partition without protection
On 12/12/2018 11:59 PM, Marc Lehmann wrote: > As you say, there are several ways, some where the user can choose to > make the files accessible and some where she can choose to not make them > available. I'm not sure what you mean by this. > The point is that the user should be in control of whether files are > accessible to other users or not. They are; if you don't want files to be accessible to someone then set up the permissions so they don't have access and/or don't give them access to mount the volume and/or run programs like gparted as root. > gparted doesn't allow that choice, and what's worse, it's not even obvious > that it potentially makes files available that normally wouldn't. Resizing a > filesystem should not expose files to other users that normally wouldn't. If you can run gparted, then you can mount the filesystem at will. While it isn't immediately obvious that resizing a btrfs filesystem will cause it to be mounted temporarily, it isn't getting you any more access than you already had. Also your typical desktop environment these days lets users click on unmounted volumes and they will auto mount them, which brings us back to setting the permissions correctly inside the volume. > Your argument could be applied to users homedirectories as well - if > gparted temporarily did "chmod 777 ~" it wouldn't be a bug according to > your logic as well. No, it wouldn't. Your argument is more like saying my home directory is 777 but I normally don't keep it mounted so nobody can access it, so now it is a problem that anyone can click on the volume to mount it and then have full access to my files. The problem is the permissions, not the mounting. > Or maybe I misunderstood you, but it seems you are saying "since the user > could choose to make files available to other users, it's not a bug that > gparted silently does it without asking or notifying the user that it would > do so". No; I'm saying that if you don't want the files available then set the permissions correctly, and if you don't want users to be able to mount the filesystem, then don't let them run gparted or mount filesystems using other tools. signature.asc Description: OpenPGP digital signature
Bug#916260: gparted mounts partition without protection
On Wed, Dec 12, 2018 at 08:46:01AM -0500, Phillip Susi wrote: > I'm not sure this can be considered a bug. Ugh. > There are several ways the user could have the filesystem mounted in a > non temporary manner and if the permissions of the filesystem allow them > access, then they can access it. As you say, there are several ways, some where the user can choose to make the files accessible and some where she can choose to not make them available. The point is that the user should be in control of whether files are accessible to other users or not. gparted doesn't allow that choice, and what's worse, it's not even obvious that it potentially makes files available that normally wouldn't. Resizing a filesystem should not expose files to other users that normally wouldn't. Your argument could be applied to users homedirectories as well - if gparted temporarily did "chmod 777 ~" it wouldn't be a bug according to your logic as well. Or maybe I misunderstood you, but it seems you are saying "since the user could choose to make files available to other users, it's not a bug that gparted silently does it without asking or notifying the user that it would do so". -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
On 12/12/2018 3:50 AM, Marc Lehmann wrote: > Package: gparted > Version: 0.25.0-1+b1 > Severity: normal > > Dear Maintainer, > > for some operations, gparted mounts partitions under /tmp/gparted-XX > without any protection > against access. This makes these partitions potentially accessible to other > users on the system while > the operation runs. > >* What led up to the situation? > > Resizing a btrfs partition. > >* What was the outcome of this action? > > While resizing, the partion was mounted under /tmp/gparted-BSeLY6, > accessible to all users, potentially allowing other users to read or write > the data: I'm not sure this can be considered a bug. There are several ways the user could have the filesystem mounted in a non temporary manner and if the permissions of the filesystem allow them access, then they can access it. signature.asc Description: OpenPGP digital signature
Bug#916260: gparted mounts partition without protection
Package: gparted Version: 0.25.0-1+b1 Severity: normal Dear Maintainer, for some operations, gparted mounts partitions under /tmp/gparted-XX without any protection against access. This makes these partitions potentially accessible to other users on the system while the operation runs. * What led up to the situation? Resizing a btrfs partition. * What was the outcome of this action? While resizing, the partion was mounted under /tmp/gparted-BSeLY6, accessible to all users, potentially allowing other users to read or write the data: drwxr-xr-x 1 root root 44 Dec 6 08:20 /tmp/gparted-BSeLY6 * What outcome did you expect instead? The partition data would not be accessible to other users. A somewhat simple fix would be to create a directory only accessible for the current user with a moiuntpoint inside, e.g,. something like: drwxr- 1 root root 44 Dec 6 08:20 /tmp/gparted-BSeLY6 drwxr-xr-x 1 root root 44 Dec 6 08:20 /tmp/gparted-BSeLY6/realmountpoint -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) Versions of packages gparted depends on: ii libatkmm-1.6-1v5 2.24.2-2 ii libc6 2.27-8 ii libgcc1 1:8.2.0-10 ii libglib2.0-0 2.58.1-2 ii libglibmm-2.4-1v5 2.50.0-1 ii libgtk2.0-0 2.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libpangomm-1.4-1v52.40.1-3 ii libparted-fs-resize0 3.2-17 ii libparted23.2-17 ii libsigc++-2.0-0v5 2.10.0-1 ii libstdc++68.2.0-10 ii libuuid1 2.29.2-1+deb9u1 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid ii dmsetup2:1.02.137-2 ii dosfstools 4.1-1 ii gpart 1:0.3-3 pn jfsutils ii kpartx 0.6.4-5+deb9u1 ii mtools 4.0.18-2+b1 ii ntfs-3g1:2016.2.22AR.1+dfsg-1 ii reiser4progs 1.1.0-3 ii reiserfsprogs 1:3.6.25-4+b1 ii xfsprogs 4.9.0+nmu1 ii yelp 3.22.0-1 -- no debconf information
