|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | More secure permissions for the user directory by default | ||||||
|---|---|---|---|---|---|---|---|
| Product: | General | Reporter: | pmladek <pmladek> | ||||
| Component: | code | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | CONFIRMED --- | QA Contact: | |||||
| Severity: | Trivial | ||||||
| Priority: | P3 | CC: | hennes.rohling, issues, matthias.huetsch | ||||
| Version: | OOo 2.0.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux, all | ||||||
| Issue Type: | TASK | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
pmladek
2006-03-07 10:13:05 UTC
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". |