On Tue, Dec 21, 2004 at 03:43:19AM +0100, Jeroen van Wolffelaar wrote: > On Tue, Dec 21, 2004 at 01:18:27AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > > _However_ if it does not exist the lab is created, if the user has a > > "insecure" umask (002) you will end up being prey to symlink attacks due > > to a race condition check this (when setting up the lab): > > If you have a umask of 002 you can expect people of the same group to > do nasty things with you... Isn't that the whole point of umask? If I > set umask of 0, I'll be vulnerable too, to a whole lot of issues. The main point here is predictability. Even if I have a 002 umask, rogue users from my same group cannot target symlink attacks against me (against files that might be mode 700 for example) if they cannot foresee what files I will create in the future. Temporary stuff which is predictable can, however, be used for this kind of attacks. Notice that a user might have an insecure umask at some point but not usually, the Lab::setup code compromises all the files he owns, not just those that are 770. > > So what you have here is a race condition because of temporary > > files. Granted, this only happens when you have a lax umask, but it could > > be prevented either by using a proper function to create temporary > > directories (tempdir() will set them up mode 700) or by restricting the > > umask to 0700 when creating the temporary directories in Lab::setup(). > > No need to extra-restrict IMHO, I don't think one should restrict > permissions above what's needed according to the user. On systems where > I have a 02 umask, I *intent* for users of the same group to be able > to write to all the stuf I do. If that's not intended, well, don't have > a 02 umask. Please, code that setups temporary stuff in all-writable location should be extra-restricted. Notice how tempfile() implementations and mktemp() implementations make temporary stuff _always_ mode 0700 for this same reason. > > I did not properly assess the issue in the initial report, but I still > > believe that Lintian has a security bug which introduces a hole under > > some conditions and that could be easily fixed. > > I, and with me one other lintian maintainer I consulted, still don't > think this is a security bug (the different issue w.r.t. removing files > however still stands). I still think it _is_ a security issue, similar bugs (not defining a stricter umask when setting up temporary stuff) have been addressed in other programs without any issues. I would like to hear why is so important to you to preserve the user's umasks in the LINTIAN_LAB temporary directory when it's: a- a temporary directory b- a target for symlink attacks since its contents are predictable Why not enforce a 077 umask there? Regards Javier
Attachment:
signature.asc
Description: Digital signature