Apache OpenOffice (AOO) Bugzilla – Issue 62858
More secure permissions for the user directory by default
Last modified: 2017-05-20 10:55:42 UTC
OOo creates the directory with user configuration with the access rights 0755 by default. It means that the user configuration is readable by anybody. I am not sure if the temporary versions of documents are stored in this directory as well. It would be a security hole, in fact. Anyway, from the security point of view, it would be better to create the user directory with permissions 0700 by default. I attach a patch that does it and works for me on Linux. Note 1: It won't help to improve the method Directory::create to accept the attribute parameter. It is because the aUserPath direcory is already created at this point. It is created earlier when OOo writes something below <aUserPath>/user/registry/cache. Note 2: I did the fix UNIX-specific because OOo does not provide the method setAttributes for the object Directory. I was not sure if File::setAttributes works on non-UNIX systems.
Created attachment 34625 [details] One possible fix for UNIX.
@ lo: Please have a look. But if the $HOME is readable by anybody it's not a great security enhancement to change only the user configuration of OOo :-).
JA: I'm not really convinced to have hardcoded access rights here. The user directory creation might better depend on the umask given by the underlying operating system. To be discussed... Lars, what is your opinion about that ?
The umask applies to the creation of the user dir. Temp files are already created in 'secure' mode. I don't see a problem here, unless the above is not true.
More applications create this kind of directory with more secure permissions by default. I see on my system, for example: drwx------ 4 pmladek users 4096 2005-08-08 19:45 .ddd drwx------ 6 pmladek users 4096 2003-03-29 22:02 .galeon drwx------ 9 pmladek users 4096 2003-10-20 10:36 .gnome drwx------ 5 pmladek users 4096 2006-01-23 16:00 .kde drwx------ 5 pmladek users 4096 2005-09-08 09:47 .licq drwx------ 2 pmladek users 4096 2004-03-02 20:33 .links drwx------ 6 pmladek users 4096 2003-08-08 20:46 .netscape I think that it depends on what kind of data are stored in the directory. I think that the OOo user conf directory includes some personal data and should be better protected. Another problem is that this directory is hidden, so the normal user often do not know that it exists at all. Then he does not know that it is readable, ...
JA->Matthias: I'd like to know you opinion regarding this request. Added you to CC list
Hi pmladek, Joost, Actually, I do agree with pmladek that we should always apply a "secure by default" strategy. While it is true that the users 'umask' is indeed applied (by 'mkdir(2)', see 'man -S 2 mkdir' on Linux), this is not "secure by default". Regardless of the users 'umask', the OOo 'user directory' is a *user* specific directory (where user private data may be stored), so that the creator of that directory should indeed specify mode 700 (instead of 777, and relying on an appropriate umask). While the proposed patch would indeed work (and I agree that it is apparently the only quick change), I don't like it as it is. The proposed patch has an inherent race condition: a 'chmod()' done some time after 'mkdir()' would leave time for possibly bad things to happen. As 'mkdir(path, mode)' already provides the right API to do the right thing, the osl_createDirectory() (resp. osl::Directory::create()) API should probably be extended to allow for the secure creation of the user directory (tree). Again, it is less important how probable an exploit would be, than to be "secure by default". Matthias
I aggree, that under a secure-by-default premise the directory should be created 700. I also aggree, that introducing the proposed fixed would violate said premise and is thus not the apropriate solution. The user-directory is currently being created when the configmgr is first bootstrapped. It's kind of a side-effect when seen from the perspective of the main application. The main application would create it, if it wasn't already there, but in the current implementation it will always be there before the userinstall code is reached. If the osl::File API is extended as Matthias (mhu) proposes one of two thing needs to happen: a) the configmgr implementation must use the extended interface and creeate the user-dir according to the secure-by-default premise, or b) the creation of the user directory must be the responsibility of the main application and the configmgr must no longer be allowed to create it's own user-layer if the base directory isn't available. I would prefere alternative (b), since it does away with an intransparent side-effect.
Could you please clarify the preferred solution and point me to the related code? I could help with implementaion then.
dispatch to framework
cd->hro: It looks like your action is required first to fix this issue. Could you please have a look. May be you can contact pmladek and give him information which code must be extended.
Unfortunately we forgot to change the owner... Better late than never!
Retargeted.
mav: Can you please take a look. Seems, that some osl file API change is needed to solve the problem.
Created attachment 73966
Reset assigne to the default "issues@openoffice.apache.org".