Jan Minář wrote: > On Fri, Jul 18, 2008 at 3:45 PM, Ben Schmidt > <[EMAIL PROTECTED]> wrote: >> Jan Minář wrote: >>> mktemp(1) creates the file securely, with 0600 permissions. That's the >>> whole point. There is no race condition. That's the whole point. >> Presuming the directory it's in is sticky or such so other users can't >> change it. I suppose it probably is on most systems, but I doubt it is >> on all... :-\ > > Interesting! I never would have thought security of code running on a > million platforms is going to be so much pain^H^H^H^Hfun!
Mmm. It's hard to know how far to go with stuff like this, too. Where does the responsibility of the programmer stop and the sysadmin start, and where does their responsibility stop and the user's start? I think it's reasonable to expect users not to open files with suspicious names with funny characters in them. If they do, they deserve what they get, same as if they open a parcel that's ticking. If they have a habit of doing such things, installing anti-virus software seems to be the in vogue way to deal with it. Particularly in Vim's case (as is the case with many Unix programs) where the shell that will be called to perform certain operations can not be predicted, so the escaping can't be determined in advance, it quickly becomes unreasonable for the programmer to deal with the totality of these issues. It can also be a waste of developer time if taken too far--the great lack of likelihood of many attacks and similarly great benefits of spending time fixing or implementing *other things* make it a no-brainer sometimes where to focus! Of course, it's where things like automatic commandline completion could compromise a system that more care needs to be taken. If the user can't see the funny file name to start with, but its existence on disk or in an archive can circumvent security, that's serious. I don't know how Vim handles things like this, but it would make sense to me to at least have a secure mode which always uses /bin/sh to do this stuff rather than the user's shell, and fully escape everything as /bin/sh requires. For power users, having an option to use their own shell and thereby get different/additional completions may be desired, but since Vim can't escape for any and all shells, this is less secure. But at least if you change an option like that, it's clear where the responsibility lies! > If creating a temporary file securely is possible at all, shouldn't > mktemp(1) do just that? And if it doesn't, is Vim source code the > right place to fix it? mktemp(1) is very old. I expect it was designed not so much to address security as integrity and privacy, primarily ensuring cooperating processes didn't clobber each other's files. It's a low priority kind of bug to fix, though. It's very unlikely that an attacker will know the precise time you're building Vim, and then successfully be able to substitute a file at the precise time in the build process that would be necessary to compromise the system (or at least the building user's account). Now, if the attacker had some way to trigger a build of Vim, e.g. a web interface, so they could start Vim building when they wanted to, and then substitute the file, it would be more of a problem (though not in the web interface case if properly configured such that the web user has low privs), or if Vim was unwisely built by a privileged user account on a cron job or something predictable like that, it could be an issue, or if you know a machine where someone regularly builds vim and can just make a script sit and wait! As it is, though, it's unlikely any attacker would even try to win these kinds of races. As has been pointed out, making a directory in /tmp is more secure. More specifically, making a directory and putting a file in it (there is a race condition there, of course...but checking/setting the mode can ensure security, I think). The directory can't be deleted and replaced unless empty, and can't be emptied if not writable. I'm not sure how Vim handles this as it runs at the moment and whether it performs enough checks to guarantee security, but even the little it does is better than just dumping files in /tmp or even using mktemp. On regular annoyance I have is that my system periodically cleans up /tmp and removes Vim's temp directories, and since a long-running Vim process created the directory, it assumes it's there and doesn't recreate it but just gives errors. I tend to manually recreate it just with mkdir, which probably isn't all that secure. I wonder whether others have similar troubles and whether it's worth getting Vim to do extra checks of this directory's existence. At the very least, I'd like a Vim command to recreate it, because I'm getting sick of typing the command in all the time. I've been meaning to look at this and make a patch, but haven't got around to it yet. > The configure can just use a fixed file name in the current directory. Mmm. That's likely to be the best thing, I think. It mostly does anyway. I didn't look in any detail at why it was creating other temporary files elsewhere, but did think it a little strange. Thanks for your work, Jan; though I haven't looked at it in detail, I'm sure we do appreciate getting these bugs ironed out, particularly when you're able to supply patches so it doesn't take development time away from other things. Smiles, Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
