Bug#437148: [scponly] svn support in scponly is unsafe
On 07.09.2007, at 11:01, Joachim Breitner wrote: Hi, Am Freitag, den 07.09.2007, 10:59 +0200 schrieb Florian Weimer: * Joachim Breitner: I think mounting the file system no-exec covers that. IIRC, Subversion directly executes the hook scripts, and this will fail in that case. Then this should be mentioned in the file. I also think that this is quite a high hurdle: Admins that want that can surely re-compile scponly. It's mentioned in the file (item 7), but I agree that this is not the target group of the Debian package. Sorry, didn’t read it all. For the rest, the debian package should come without svn support. The README.Debian could describe the disabled features, and under what circumstances they are save, and how best to recompile scponly. The package could create two binaries, one that supports just scp/sftp, and another one for the rest. Sounds good, but that’s up to the maintainer. Thomas, are you reading this? I am, I'm doing an overhaul of the package soon. Tom For the stable security update, it's probably best to just disable Subversion/Unison/rsync. I agree. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: [scponly] svn support in scponly is unsafe
* Joachim Breitner: >> I think mounting the file system no-exec covers that. IIRC, >> Subversion directly executes the hook scripts, and this will fail in >> that case. > > Then this should be mentioned in the file. I also think that this is > quite a high hurdle: Admins that want that can surely re-compile > scponly. It's mentioned in the file (item 7), but I agree that this is not the target group of the Debian package. > For the rest, the debian package should come without svn > support. The README.Debian could describe the disabled features, and > under what circumstances they are save, and how best to recompile > scponly. The package could create two binaries, one that supports just scp/sftp, and another one for the rest. For the stable security update, it's probably best to just disable Subversion/Unison/rsync. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437148: [scponly] svn support in scponly is unsafe
Hi, Am Freitag, den 07.09.2007, 10:59 +0200 schrieb Florian Weimer: > * Joachim Breitner: > >> I think mounting the file system no-exec covers that. IIRC, > >> Subversion directly executes the hook scripts, and this will fail in > >> that case. > > > > Then this should be mentioned in the file. I also think that this is > > quite a high hurdle: Admins that want that can surely re-compile > > scponly. > > It's mentioned in the file (item 7), but I agree that this is not the > target group of the Debian package. Sorry, didn’t read it all. > > For the rest, the debian package should come without svn > > support. The README.Debian could describe the disabled features, and > > under what circumstances they are save, and how best to recompile > > scponly. > > The package could create two binaries, one that supports just > scp/sftp, and another one for the rest. Sounds good, but that’s up to the maintainer. Thomas, are you reading this? > For the stable security update, it's probably best to just disable > Subversion/Unison/rsync. I agree. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: [scponly] svn support in scponly is unsafe
Am Freitag, den 07.09.2007, 10:49 +0200 schrieb Florian Weimer: > * Joachim Breitner: > > >> These files have specific filenames at specific locations relative to > >> the svn repository root. > > > > But since I can put a repository _anywhere_ by just copying it there, > > how do you want the admin to prevent the user running it’s hook > > commands? > > I think mounting the file system no-exec covers that. IIRC, > Subversion directly executes the hook scripts, and this will fail in > that case. Then this should be mentioned in the file. I also think that this is quite a high hurdle: Admins that want that can surely re-compile scponly. For the rest, the debian package should come without svn support. The README.Debian could describe the disabled features, and under what circumstances they are save, and how best to recompile scponly. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: [scponly] svn support in scponly is unsafe
* Joachim Breitner: >> These files have specific filenames at specific locations relative to >> the svn repository root. > > But since I can put a repository _anywhere_ by just copying it there, > how do you want the admin to prevent the user running it’s hook > commands? I think mounting the file system no-exec covers that. IIRC, Subversion directly executes the hook scripts, and this will fail in that case.
Bug#437148: [scponly] svn support in scponly is unsafe
Hi, Am Freitag, den 07.09.2007, 00:45 -0700 schrieb Kaleb Pederson: > Thanks Florian, > > The following are now disabled for svn: > > "editor-cmd", > "diff-cmd", > "diff3-cmd", (just added) > "config-dir", But that does not prevent commiting to a repository with hooks, right? You write in the security docs: > These files have specific filenames at specific locations relative to > the svn repository root. But since I can put a repository _anywhere_ by just copying it there, how do you want the admin to prevent the user running it’s hook commands? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: [scponly] svn support in scponly is unsafe
Thanks Florian, The following are now disabled for svn: "editor-cmd", "diff-cmd", "diff3-cmd", (just added) "config-dir", The following are disabled for svnserve: "daemon", "listen-port", "listen-host", "foreground", "inetd", "threads", "listen-once", The following for rsync: "rsh", "daemon", "rsync-path", (this and below just added) "address", "port", "sockopts", "config", "no-detach", And the following for unison: "-rshcmd", "-sshcmd", "-servercmd", "-addversionno" (just added) Where documented, the respective short options for the above are disabled. I updated the security document to include the changes you recommend, and then a couple of others that come to mind. The latest version of the security document is available here: http://scponly.cvs.sourceforge.net/scponly/scponly/SECURITY?view=markup We'll continue to look at it and see if there is anything else that we missed. Thanks again for the help. --Kaleb On Thursday 06 September 2007, Florian Weimer wrote: > >> Furthermore, in light of comments on the debian list, I just > >> disallowed --editor-cmd, --diff-cmd, and --config-dir... but that still > >> doesn't help with the editor cmd and diff cmd being specified in config > >> files. > > --diff3-cmd is problematic, too. For rsync, you need to disable > daemon mode (at the very least). > > The security guide must mention that you need to lock down > ~/.subversion, ~/.ssh, ~/.unison and maybe a few more directories. signature.asc Description: This is a digitally signed message part.
Bug#437148: [scponly] svn support in scponly is unsafe
>> Furthermore, in light of comments on the debian list, I just >> disallowed --editor-cmd, --diff-cmd, and --config-dir... but that still >> doesn't help with the editor cmd and diff cmd being specified in config >> files. --diff3-cmd is problematic, too. For rsync, you need to disable daemon mode (at the very least). The security guide must mention that you need to lock down ~/.subversion, ~/.ssh, ~/.unison and maybe a few more directories. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437148: [scponly] svn support in scponly is unsafe
Hi Kaleb, just replying to get the mail into the Debian BTS. Please keep [EMAIL PROTECTED] in the CC about this topic. I’m not testing these now, but maybe the scponly package maintainer will. Greetings, Joachim Am Dienstag, den 04.09.2007, 13:38 -0700 schrieb Kaleb Pederson: > Hello, > > If you are familiar with rsync and unison and use them with scponly, please > take a look at the comments at the bottom of the bug report and test with the > latest CVS -- specifically options that use configuration files that can't be > identified on the command line. I had trouble finding adequate documentation > on unison, so testing in that area is appreciated. > > Aside from specifying which commands might have the right to execute by using > an LD_PRELOAD mechanism, I'm not sure if there is much that can be done. > > We have fairly recently refined the rsync support to disallow starting it as > a > daemon, and a few other things that could also cause problems, so I believe > it won't accept a config file on the command line, etc., and I believe it to > be safe at this point. > > Furthermore, in light of comments on the debian list, I just > disallowed --editor-cmd, --diff-cmd, and --config-dir... but that still > doesn't help with the editor cmd and diff cmd being specified in config > files. > > As far as we know, a system secured using the practices set forth in the > security guide will be secure. If there are other best practices that can be > added to it, or you have other suggestions and/or comments, please let us > know. > > Thanks. > > --Kaleb > > On Tuesday 04 September 2007, Joachim Breitner wrote: > > Hi, > > > > please read through: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437148 > > > > Basically: Allowing svn or svnserve is unsafe. > > > > Greetings, > > Joachim > -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: [scponly] svn support in scponly is unsafe
Hi, Am Dienstag, den 04.09.2007, 13:10 -0700 schrieb Kaleb Pederson: > Yes, you are exactly right. This was discovered a while ago and documented > in > our SECURITY document currently only in CVS. You can see it here: > > http://scponly.cvs.sourceforge.net/scponly/scponly/SECURITY?revision=1.1&view=markup > > We have debated whether or not support for svn and svnserve should be removed > entirely or if it should be controllable by the system administrator. As the > OS can be configured to safely allow svn/svnserve, I think we leaned towards > making it obvious what the ramifications of the different options are and > leaving it up to the discretion of the system administrator. For instances > where the svn repository is actually controlled by the administrator, this > makes perfect sense. > > Please forgive us that this wasn't brought to the attention of the community > earlier, unfortunately our time limits us more than we like. > > Community members, please let us know what your feelings on this are so that > we have as few surprises as possible with our next release. I assume then that svn/svnserve support is by default off in the original package and that the Debian package should also not have svn/svnserve support. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
