Re: Akonadi's unix sockets location
On 03/21/2010 10:44 AM, Jonathan Underwood wrote: On 19 March 2010 23:52, Lennart Poetteringmzerq...@0pointer.de wrote: That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. To what extent would the security issues associated with files in /tmp be mitigated with a polyinstantiated /tmp directories? Should Fedora move to that as a default? Yes a lot of this would be fixed, but it is very confusing to have different views of /tmp. I have it setup right now and am bit by root having a different view of /tmp then my user account. And I understand the technology. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sun, 21.03.10 14:44, Jonathan Underwood (jonathan.underw...@gmail.com) wrote: It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. To what extent would the security issues associated with files in /tmp be mitigated with a polyinstantiated /tmp directories? Should Fedora move to that as a default? The major security issues would certainly go away that way, but I don't think that such a behaviourial change would be a good idea. /tmp has always been a shared namespace, and some apps might actually depend on that to exchange files between users. The FHS assumes a single namespace for the entire fs hierarchy and departing from that might create various unexpected problems. Starting from admins who don't expect a weirdness like this, but also applications that break with behaviour like that. To my knowledge the Debian folks experimented with this a couple of years ago, and even wanted to make it the default (but didn't in the end, afaics). Might be interesting to learn about the results of their experimenting. Instead of changing the semantics of /tmp which is already way to established with all its brokeness and weird semantics, I'd rather like to see a new dir added /var/run/users/$USER/ that does not suffer by all the problems and introduces new, clean and well defined semantics. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 19 March 2010 23:52, Lennart Poettering mzerq...@0pointer.de wrote: That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. To what extent would the security issues associated with files in /tmp be mitigated with a polyinstantiated /tmp directories? Should Fedora move to that as a default? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: Ok if they are from the same login session and same UID it is reasonable to expect them to share /tmp. Iirc, it would be more FHS compliant to use /var/tmp instead. Regards Till pgp70p2xBXwfN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, 20.03.10 10:34, Till Maas (opensou...@till.name) wrote: On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: Ok if they are from the same login session and same UID it is reasonable to expect them to share /tmp. Iirc, it would be more FHS compliant to use /var/tmp instead. No. Unix sockets should definitely be cleaned up on reboot. Hence they belong in /tmp better than in /var/tmp. http://www.pathname.com/fhs/2.2/fhs-5.15.html Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, Mar 20, 2010 at 11:34:58AM +0100, Lennart Poettering wrote: On Sat, 20.03.10 10:34, Till Maas (opensou...@till.name) wrote: On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote: Ok if they are from the same login session and same UID it is reasonable to expect them to share /tmp. Iirc, it would be more FHS compliant to use /var/tmp instead. No. Unix sockets should definitely be cleaned up on reboot. Hence they belong in /tmp better than in /var/tmp. Why do they need to be cleaned up on reboot? The problem with sharing files between applications using /tmp is this specification: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES | Programs must not assume that any files or directories in /tmp are | preserved between invocations of the program. So in case there will be a file system for /tmp that automatically removes files once they are not open anymore, abusing /tmp for this will fail. Regards Till pgpI0hBm6QZcP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, 20.03.10 12:42, Till Maas (opensou...@till.name) wrote: Unix sockets should definitely be cleaned up on reboot. Hence they belong in /tmp better than in /var/tmp. Why do they need to be cleaned up on reboot? After the program that listened on them exited they are useless and cannot be reused, they hence *must* be removed before another program can listen on them again. The problem with sharing files between applications using /tmp is this specification: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES | Programs must not assume that any files or directories in /tmp are | preserved between invocations of the program. So in case there will be a file system for /tmp that automatically removes files once they are not open anymore, abusing /tmp for this will fail. Uh? First of all, such an fs does not exist. Secondly, as mentioned a unix socket is useless in the fs after the program that listened on it exited, hence automatically deleting the unix socket as soon as it exited would actually be a good idea. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 03/20/2010 07:48 AM, Lennart Poettering wrote: Secondly, as mentioned a unix socket is useless in the fs after the program that listened on it exited, You mean in the context of a 'shared secret'-named sockets, right? In general. a socket /tmp/socket can just sit there and be reused by whatever programs fancy to open it for reading and/or writing. Or have I misunderstood something in this discussion? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Sat, 20.03.10 10:37, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 03/20/2010 07:48 AM, Lennart Poettering wrote: Secondly, as mentioned a unix socket is useless in the fs after the program that listened on it exited, You mean in the context of a 'shared secret'-named sockets, right? In general. a socket /tmp/socket can just sit there and be reused by whatever programs fancy to open it for reading and/or writing. Or have I misunderstood something in this discussion? No. Unix sockets cannot be reused. If the application that created the socket via calling bind() for the path closed the socket, the socket node is useless in the file system. Another bind() on it will return ADDRINUSE and a connect() on it will return ECONNREFUSED. Only after it was deleted it may be created anew with bind() and then be used again. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 14:52, Juha Tuomala (juha.tuom...@iki.fi) wrote: [Connection] SocketDirectory=/tmp/akonadi-myuser/ into $HOME/.config/akonadi/akonadiserverrc How about setting that as default, away from $HOME that can be a NFS filesystem? I have had problems with it sometimes and that's probably not a rare case. That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 08:38, Rex Dieter (rdie...@math.unl.edu) wrote: Juha Tuomala wrote: https://bugs.kde.org/show_bug.cgi?id=179006#c5 in the current version of Akonadi server you can specify a custom socket path by entering [Connection] SocketDirectory=/tmp/akonadi-myuser/ into $HOME/.config/akonadi/akonadiserverrc How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. If KDE really does this, it is really broken. hostname is unsuitable for use cases like this, since on many Fedora/RH systems it is just localhost. And then very often it is highly dynamic, sometimes even changing with DHCP. If you want to identify a machine, use the D-Bus machine id. If you don't want to link against the libdbus libraries (which you probably should), then at least read /var/lib/dbus/machine-id and use that (possibly with a fallback to the hostname, in case the admin is a nut). The dbus machine id is the only suitable ID for usecases like this: it is static, bound to the installation, and widely available. In addition to this username is unsuitable for use cases like this too, since it opens the door to DoS attacks by other users since they can guess you socket path and create the socket and hence make it impossible for you to use it. If you want to do this properly, do something like this: ~/.kde/socket-dbusid → /tmp/ksocket-random/socket Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 10:54, Matthias Clasen (mcla...@redhat.com) wrote: Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. Abstract sockets are not particularly useful for anything but system services that are only started once, and very early during bootup. Why? because they are not namespaced: every user can take every name he wants. If a system service that is restartable or started late at bootup needs a specific name then some evil user might already have taken it away, creating a DoS situation. As soon as a system is booted up to a level where non-system users can login abstract namespace sockets must use randomized names, to avoid these DoS issues. And a reference to those names would probably be have to be written to the file system, so that it can be found by other applications. And as soon as that happens, most advantages of sockets that don't live in the fs hierarchy are gone. Abstract sockets are a tool that is only really useful during early boot. For everything else I don't think it really has any advantages over fs sockets. However, they are harder to discover, which sucks. In summary: unless you hack very low-level Linux-specific software forget about abstract sockets. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? Tuju -- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
Juha Tuomala wrote: On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
Juha Tuomala wrote: On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? fyi, tracking here, https://bugzilla.redhat.com/show_bug.cgi?id=574056 -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16 Mar 2010, Rex Dieter wrote: Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. Could that be it: http://techbase.kde.org/KDE_System_Administration/Configuration_Files#Example:_Dynamic_Entries Tuju -- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 10:54 AM, Matthias Clasen mcla...@redhat.com wrote: Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. People - reliably finding other programs and initiating communication with them is 99% of the reason that DBus was created and exists in the OS. In this case, the right thing is to claim a bus name (org.blah.MyApp), export a method on it org.blah.MyApp.GetSocket, which returns the randomly-named path to your socket in /tmp. Using abstract sockets does NOT mean you don't have to worry about permissions. Any other uid can still connect to the socket, so you either need to do some sort of peer credentials if you want to restrict it to the same uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 03/16/2010 11:17 AM, Colin Walters wrote: On Tue, Mar 16, 2010 at 10:54 AM, Matthias Clasenmcla...@redhat.com wrote: Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. People - reliably finding other programs and initiating communication with them is 99% of the reason that DBus was created and exists in the OS. In this case, the right thing is to claim a bus name (org.blah.MyApp), export a method on it org.blah.MyApp.GetSocket, which returns the randomly-named path to your socket in /tmp. Using abstract sockets does NOT mean you don't have to worry about permissions. Any other uid can still connect to the socket, so you either need to do some sort of peer credentials if you want to restrict it to the same uid. PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. Processes running with different UID communicating over /tmp will break in a namespace environment. Evil users have successfully in the past caused privileged apps to do evil things when the priv apps do stuff in /tmp. I believe it is a good idea to avoid priv apps using any directory where random users can write. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walsh dwa...@redhat.com wrote: PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. In this case I believe it's a per-user service. In which case you don't have much of a choice, because you can't use $HOME or you'll be broken by the sysadmins that inflict NFS on users. The dbus session socket is currently in /tmp, but with a random name, and the session bus rejects connections by processes not matching its own uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 03/16/2010 12:29 PM, Colin Walters wrote: On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walshdwa...@redhat.com wrote: PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. In this case I believe it's a per-user service. In which case you don't have much of a choice, because you can't use $HOME or you'll be broken by the sysadmins that inflict NFS on users. The dbus session socket is currently in /tmp, but with a random name, and the session bus rejects connections by processes not matching its own uid. Ok if they are from the same login session and same UID it is reasonable to expect them to share /tmp. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
