Closed Bug 70931 Opened 24 years ago Closed 12 years ago

Override salted Profile directory

Categories

(Core Graveyard :: Profile: BackEnd, enhancement)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.4beta

People

(Reporter: sds, Assigned: ccarlen)

References

Details

(Whiteboard: UBS (Union Bank Of Swiss))

Attachments

(1 file, 4 obsolete files)

fresher patch
22.92 KB, patch
Details | Diff | Splinter Review
when I create a profile with 'mozilla -profilemanager', I specify the profile directory which is then padded with "<profile-name>/junk.slt". There should be a way to override this very annoying behavior. If I specify a directory, this is what I mean, and nothing should be appended to it!
See bug 56002. This is in place as a security feature to prevent a whole class of attacks that involve reading the profile and/or writing things into the profile (which is in a known location). Over to profile manager:backend to decide whether we should provide a way to override this behavior.
Component: Preferences → Profile Manager BackEnd
over to default owners
Assignee: matt → ccarlen
QA Contact: sairuh → gbush
Changing to RFE even though i think this is a really bad idea (from a security standpoint that is).
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: salted profile dir won't go away! → [RFE] Override salted Profile directory
This is an intentional security feature. It's unlikely that it will be removed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → Future
verify
Status: RESOLVED → VERIFIED
Bah. Intentional it might be, but (on Mac OS at least) it's mildly offensive -- any file or folder (especially one inside the `Documents' folder!) should have a name which humans can understand.
Conrad, who has asked to "remove" that feature? As far as I understand, the request was to have an option to "override" this feature if the user does not want it. Wouldn't helpwanted/future/nobody@mozilla.org be more appropriate than a WONTFIX? Bug 56002 is rather long, but when I read it some time ago I thought the behaviour is to reuse already existing non-salted profiles. If this is true, do you suggest that people who don't want a salted profile directory use an external utility program to create a profile in a non-salted directory that is then detected and reused by mozilla? Isn't an option to the profilemanager the simpler solution?
Is there any currently known way to share profiles? I have a profile on my work machine in ~/.mozilla/akkana (made before salts existed) and I'd like to copy it to my home machine, but every time I try I find that it ignores the old profile and creates a new one with a salt (and I can't copy files between the two because the full pathnames don't match). I don't mind doing some hand editing, I just haven't managed to figure out what to edit to get it to accept the saltless profile dir. If someone can tell me how to make this happen, I'll be happy to document it on mozilla.org somewhere (the customizing document? Is there a better place?) I'm sure there are others who would like to know how to share profiles.
Akkana, this will all work when relative path names are used for profiles and the profile mgr will prompt you to find a missing profile dir. That bug isn't 0.9 so, in the meanwhile, try this. Edit the file ~/.mozilla/appreg. This contains the path to the profile dir for each profile. Chop out the salted part from that path (or add the salted part from the other registry if you want). Then moz will find your proifle dir. If it finds the dir, it won't create a new one which will be salted. Then, there are various paths in prefs.js - those to your mail folder, etc. Edit those as well.
Let's reconsider this (please dupe or add dependencies if appropriate). The purpose of the salt directory is to make the path to the user profile directory unguessable by an attacker. If the user specifies a nonstandard location for the profile in the Create Profile dialog, this satisfies the unpredicatability requirement, and salting is superfluous. So in deference to the users who find the salting annoying, let's not salt when using a nonstandard profile location.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: Future → ---
Put that way - easy enough. I'll do it for 0.9.5
Target Milestone: --- → mozilla0.9.5
Additionally, please consider making the paths in the prefs files relative. This would allow someone to move the prefs dir around on a system or between systems without breaking everything.
Relative paths are in Bug 12911
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Attached patch patch (obsolete) — — Splinter Review
Sorry this sat here so long - it only took a few minutes to fix one I got around to it. The patch makes it so that, if the profile dir to be created is outside of the default location, it is not salted. Note that if you explicitly picked the default location, it is still salted. I think this is right (safe). Do people agree? If so, review it.
Status: REOPENED → ASSIGNED
Comment on attachment 55254 [details] [diff] [review] patch Looks good to me. r=mstoltz.
Attachment #55254 - Flags: review+
the "recur" flag only works on Mac, on other platforms Contains will return true for any path that starts with the default Path no matter how many levels are added. At one point I thought the discussion turned toward only salting if the leaf directory name was "default", not if it was in the standard parent directory? I don't think the patch fulfills the thrust of this RFE since 1) it's not at all obvious that people have to go to a different directory root to avoid the salt, and 2) the fact of whether a salt is going to be added or not is completely invisible. A few folks may be aware of this fix, but basically the majority of folks will be in exactly the same situation as now. I like the suggestion from bug 97180 that the salted part be added to the first-level directory name rather than creating an extra empty level. Saves an empty directory, makes the salting obvious on the screen people see, and then people could remove it at their own risk. Most won't, but for those who do it'll be a lot clearer what's going on and what to do.
> the "recur" flag only works on Mac I hope there's a bug on that somewhere. It shouldn't make much difference here though. > At one point I thought the discussion turned toward only salting if the > leaf directory name was "default" Good point. Mitchell - would that make it unguessable enough? I think showing the salted name in the profile mgr UI and giving the user the ability to remove it would confuse more people than it would help. If the way to work around it is documented, I think it would be sufficient.
I'm fine with only salting the name if the name is "default." I think we should get rid of the extra directory completely. When someone creates a "default" profile, change the name to something unpredicatable. Don't add an option to the UI regarding salting, it should be a feature that's completely transparent to users.
Mass move to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Heeeey - did someone check this in? Mozilla lost my non-standard profile (nightly 2001112508). So I recreated it. And guess what? No salt. :)
I just tried this with 2001112508 (Windows 2000), and it still salts for me. Something else I noticed - I'm not sure if it's covered under this bug or not. The profile creator insists on appending the username to the directory path. So if I manually choose "c:\path" it will make the directory "c:\path\username". Will this behaviour remain even after the salting is overridden and, if so, should I open a separate bug for it? (I don't remember it doing this in the past, but it's been so long since I've created a new profile, rather than recycling my old 4.x non-salted profile directories, that I can't comment on any kind of recent behaviour.)
> The profile creator insists on appending the username to the directory path. That's right. For every profile created, a directory to hold its contents (username\) needs to be created. It has always done that and it's not a bug.
Right. I'm off to create a new bug report then. Half of my objection to salting was that it took my manually provided path (saying *exactly* where I wanted my profile data stored) and appended something I didn't want to it. What if I want my data put in "c:\My Documents and Settings\JasonB\Mozilla"? Salting aside, I take it there is NO way of making Mozilla honour the above request?
Yahoo, no more salt! [goes to generate a new profile and copy it to every machine] I haven't seen the new UI for specifying the path (having trouble installing today's build, the installer bombs out and has to be manually assisted), but if we're always going to create a new directory named after the profile, I hope the UI makes this clear, e.g. "Directory in which to create a new directory called [profilename]" rather than "Path to new profile directory". Otherwise I know most of us are going to forget and be forever creating profiles with pathnames like .mozilla/akkana/akkana. Alternately, could it just use the last component of the pathname as the profile name? (I suppose that makes for difficult UI since the profile name would then be shown in two places and would have to be kept in sync.)
I've already opened up two bug reports on this <profilename> behaviour (bug 111940 and bug 112023). One was immediately marked as WONTFIX, the other is, no doubt, on the verge of receiving the same treatment. I was ecstatic to here that we were at the end of this salting saga - only to discover that the profile manager insisted on adding <profilename> as a subdirectory - again completely ignoring the explicit path entered by the user. Either it should not do this, or the UI for the profile manager should inform users that this is going to happen (whether they like it or not).
-> 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Help! It's salting again. I just tried on a machine with no .mozilla at all. First it pretends that my old .netscape is a profile called "akkana"; if I let it convert, then I end up with .mozilla/akkana/[salt]. If I delete the non-profile from NS4 first, and create a new profile, the profile manager shows me the directory .mozilla/akkana (there's a Choose button but I didn't press it since that was the directory I wanted) but when I create the profile, again it's created under .mozilla/akkana/[salt]. Did the no-salting fix get regressed? Or is there a trick I'm missing? And is it considered a problem that we aren't honest with the user about the directory where the profile will go (by not showing the salt)?
> Help! It's salting again. That's because this was never fixed. There were some reports of no salt, but I don't believe them. The code hasn't changed. It will soon.
Attached patch new patch (obsolete) — — Splinter Review
This patch: (1) Appends salt rather than creating a salted subdir (2) Only salts if the name is the default name Some more work was done to make the "default" name be consistent. Before, there was a hardcoded string which was used to create a default profile without any UI - as when launching the app for the first time with no old profiles to migrate. Then, there was a 2nd localizable string, "Default User", used in the UI. Now both cases use the same string from a bundle. I decided to use "Default User" for both. I can't decide if "default" is better than "Default User" in case anybody has an opinion on that ;-)
Attachment #55254 - Attachment is obsolete: true
Can I get some r/sr of the last patch? It would be nice to have this behind us in 0.9.8.
In progress, but not gonna make 0.9.8. -> 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Again, can I get some review of the newer patch? Since this is an RFE, it may have to be futured soon if I don't land it.
Comment on attachment 63276 [details] [diff] [review] new patch Should the "Default User" string be localized? What if someone runs two different localizations of the product on the same machine, and tries to make or share profiles? Other than that, sr=sfraser
Attachment #63276 - Flags: superreview+
I also didn't like "Default User", because of directories with spaces being unix-unfriendly and tending to break scripts. And Simon's proably right that localizing it is better. Otherwise, I don't see any obvious problems with the code; will test it tomorrow.
I have a new patch which again uses "default" when a default profile is made from the back-end. The string in the UI is still the localized string from the chrome ("Default User" in en-US) This localized string has to be checked for as well as "default" when deciding whether to salt or not. Problem is, and embedding app might not have this bundle, or the default name it uses in its own UI might be something different, so comparing to the string from our bundle would be useless. There's a way around this - not have a default name in the UI. That is, the field comes up blank and the user needs to type in something in order to proceed. If that's not objectionable, I'd like to do that.
At UBS, their deployment engine processes some scripts during the installation. Thus, they need to fully precreate a profile path to access any contents of the profiles at any time. Salted dirs make such processes more difficult. Appends salt rather than creating a salted subdir ---- Does this term mean that 'salt' is appended to a profile-path which was created using the profile manager? Thanks Niranjani
Whiteboard: UBS (Union Bank Of Swiss)
> Does this term mean that 'salt' is appended to a profile-path which was created using the profile manager? The patches here aim to salt only the default profile name. Others, made by the user, won't be salted.
Attached patch another patch (obsolete) — — Splinter Review
This patch gets around the problem I mentioned on comment #37 about checking against a string from a localizable bundle. In the wizard, the profile name now starts out blank, but focused and ready to type into - much more convenient. A blank name is checked for as well as other possible problems with the name on the wizard page validation function, rather than at the end of the wizard. Need reviews.
Attachment #63276 - Attachment is obsolete: true
CC'ing Marlon for his opinion on not having a default profile name in the wizard.
Is it not possible to simply display the text "default" somewhere in the UI but not use it as input? That way the user will know what they are getting if they leave the input blank.
Since they can't leave it blank, there's no question as to what they're getting.
> The patches here aim to salt only the default profile name. Others, made by the > user, won't be salted. I don't understand. If it can't be blank - just what exactly is the "default profile name"? In the past the default was used if no change was made. If your propose UI now comes up blank, but will not allow you to continue unless you change it from blank, how is there a default? (Unless you think that somebody might actually type in "default" as their profile name?) Or are you simply saying that you changed your mind about how to approach things between post #39 and #40? (My apologies if this is SPAM but it's not entirely clear what approach is being taken here.)
Jason, there are two sources of the default name: (1) the back-end uses "default" from a hardcoded string when there are no profiles and none to migrate. It creates that profile without showing the UI. (2) currently, the profile wizard uses "Default User." With the patch, (1) will be salted and in (2), there will be no default. Unless they enter "default" it won't be salted.
With today's linux build, if I move aside .mozilla and then run, I first get 41 repetitions of this assert: ###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file ../../dist/include/string/nsDependentString.h, line 54 Then I get the dialog about converting an NS4 profile. (I have never successfully managed to persuade mozilla to ignore my NS4 profile. Is there a secret to that?) If I say yes, then I get 4 repetitions of: ### nsCacheProfilePrefObserver::Observe [topic=nsPref:changed data=browser.cache .disk.enable] followed by ###!!! ASSERTION: the path does not exist. see bug #55444: 'exists', file nsPre fMigration.cpp, line 2000 and two repetitions of ###!!! ASSERTION: failed to copy pop file: 'NS_SUCCEEDED(rv)', file nsPrefMigrat ion.cpp, line 1840 then five repetitions of ### nsCacheProfilePrefObserver::Observe [topic=nsPref:changed data=browser.cache .disk.enable] then pldhash: for the table at address 0x0x81d0504, the given entrySize of 28 probabl y favors chaining over double hashing. pldhash: for the table at address 0x0x8328a94, the given entrySize of 28 probabl y favors chaining over double hashing. ###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file .. /../dist/include/string/nsDependentString.h, line 54 ###!!! Break: at file ../../dist/include/string/nsDependentString.h, line 54 ###!!! ASSERTION: nsDependentString must wrap a non-NULL buffer: 'aPtr', file .. /../dist/include/string/nsDependentString.h, line 54 ###!!! Break: at file ../../dist/include/string/nsDependentString.h, line 54 WARNING: and then it hangs and I have to kill it. If I remove the .mozilla it created and try again, this time saying "manage profiles" instead of letting it convert, I get a crash before the profile dialog comes up: #0 0x40966856 in nsWebShellWindow::LoadContentAreas (this=0x81861d8) at nsWebShellWindow.cpp:1454 #1 0x40965910 in nsWebShellWindow::OnStateChange (this=0x81861d8, aProgress=0x82384cc, aRequest=0x8284440, aStateFlags=786448, aStatus=0) at nsWebShellWindow.cpp:1281 #2 0x4121c65f in nsDocLoaderImpl::FireOnStateChange (this=0x82384b8, aProgress=0x82384cc, aRequest=0x8284440, aStateFlags=786448, aStatus=0) at nsDocLoader.cpp:1109 #3 0x4121b770 in nsDocLoaderImpl::doStopDocumentLoad (this=0x82384b8, request=0x8284440, aStatus=0) at nsDocLoader.cpp:749 #4 0x4121b47a in nsDocLoaderImpl::DocLoaderIsEmpty (this=0x82384b8) at nsDocLoader.cpp:645 #5 0x4121b1e9 in nsDocLoaderImpl::OnStopRequest (this=0x82384b8, aRequest=0x8315698, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:575 #6 0x40b9b275 in nsLoadGroup::RemoveRequest (this=0x81c94c0, request=0x8315698, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:526 #7 0x40c0329d in nsJARChannel::OnStopRequest (this=0x8315698, jarExtractionTransport=0x82e2c9c, context=0x0, aStatus=0) at nsJARChannel.cpp:615 #8 0x40c221a8 in nsOnStopRequestEvent::HandleEvent (this=0x82e37a0) at nsRequestObserverProxy.cpp:212 (further stack trace or variable info on request.)
It turns out these are all unrelated problems. They happen without the patch, too. So the problems block testing of the patch but aren't caused by it.
The DependentString asserts should now be fixed. The other problem sounds like today's Linux smoketest blocker...
With various fixes for today's blockers, the patch works in the limited testing I've done on linux. newProfile1_2.properties and newProfile1_2.dtd don't end with newlines -- doesn't that cause problems? The rest of the code looks fine, r=akkana. On the issue of whether to put a default in the dialog. I think it's a little confusing to have it blank, and would lean toward prefilling it and selecting the contents (so that the user can start typing without having to click or select anything), but Conrad pointed out that people won't see this dialog unless they explicitly ask for it, and anyone who asks probably intends to choose a name ... and I can't argue with that logic. I"ll defer to Marlon (or whoever feels strongly about it), and that's an easy thing to change after the fact so the code probably shouldn't wait on a definitive answer. I also raised a question: with the old code, if I don't automigrate and instead "manage profiles", delete the name for the profile it wants to automigrate then create a new profile, I find that every time I install a new nightly it prompts me to automigrate again, ignoring the existing profile (but only on the first run, after which it's content to use the existing profile). I was hoping that the fix for this bug would also fix that problem (not everyone wants to automigrate, especially if there's a big batch of mail in the NS4 profile) but I can't test that without a new nightly. If it still happens, it's a separate bug (but relevant for the folks who have said they want to make a master profile to distribute to their users, since some of those users might have NS4 profiles).
Simon, can you sr= the latest patch? The gist of it vs. the last is in comment #40.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Is there an FAQ or can someone tell me how to un-salt a directory manuly?
I'd give a lot to know that information myself. I don't, however, think it's possible. At least nobody could tell me how to do this many months ago when I asked a simiilar question. It has something to do with the "registry.dat" file. I've tried editing the text string in there, to change it from its salted position to another one I created, but that didn't work.
Wouldn't it be better to let the user decide wether he wants to salt a directory or not. I Think a checkbox in the front-end named "salt directory (more secure)" or "obfuscate directory..." that is checked by default would be appropriate.
manual un-salting: 1. rename your 123456.slt to mydir.slt 2. replace 123456.slt with mydir.slt in "~/.mozilla/appreg"
"~/.mozilla/appreg" does not exist on Windows systems. (I don't know about Macs.) I suspect that this is Linux/Unix only.
for windows it's something like Application Data\Mozilla\registry.dat please read the latest release notes, they indicate where the file lives and what its name is.
Yes, registry.dat under Windows is the file that controls the location of the profile directory, but it cannot be hand-edited. I have tried to do so and it had no effect. Apparently only by changing the C++ source code that controls the creation of this file can you modify the profile directory location that it points to. (Which is not practically possible for most people.)
Is this ever going to be implemented? It looks like the patch has been done and awaiting verification for over eight months. Are the higher ups concerned that if this was implemented most people would remove salting from their profile, and end up solving 99% of the salting related issues so no one will spend the time trying to fix them?
Comment on attachment 67900 [details] [diff] [review] another patch um, afaict this patch changes the semantics of a frozen interface and is therefore unacceptable.
> um, afaict this patch changes the semantics of a frozen interface and is therefore unacceptable. Wrong. There are no changes to idl ifaces in the patch, much less frozen ones.
ccarlen, while that is true, this patch does change how the useExistingProfiles parameter behaves, doesn't it?
Not to get impatient, but is this “bug/feature” done? If so I would like the Assignee ccarlen@netscape.com (Conrad Carlen) to nominate it for 1.2beta branch that has just opened up. With 10 votes, that more them most of the other submited paches http://bugzilla.mozilla.org/show_bug.cgi?id=1.2b
there is no 1.2 beta branch and will not be. 1.2b will be released from trunk, as were 1.1a and 1.1b and 1.2a...
Summary: [RFE] Override salted Profile directory → Override salted Profile directory
Attached patch Less bitrotted patch (obsolete) — — Splinter Review
The patch was way bitrotted. Since I also would like to see this checked in (salted profiles make my own profile management more complicated, plus I'm tired of having people outside mozilla complain to me about how they don't use mazilla because they can't prepare profiles for their users) I have attempted to bring it up to date. String and file classes have apparently both had significant changes, so someone should probably look over the changes and make sure they're doing the same thing as the old code was supposed to. Please test, those of you who want to see this!
Attachment #67900 - Attachment is obsolete: true
Akkana, thanks for updating it. I have another massive profile mgr patch in my tree now, but I can review your update. Sorry this fell off my radar :-/
Target Milestone: mozilla1.0.1 → mozilla1.2beta
Our office is anxiously awaiting some resolution to this issue as we have a few hundred windows users who cannot move out of Netscape 4.8 until the salted profile issue is resolved. Have there been any updates with a manageable solution for windows to not use salted profiles?
Finding the salted directory isn't too hard in a corporate type domain environment since each logon user will have a separate profile and %appdata% path. Therefore you really should only have one salted directory to worry about and can just grab a dir listing to find it. For example, below is a vbscript snipet that will do that. To do it in batch, just cd to the profile\profilename and then "cd *.slt" Example vbscript: Function GetDest ' Requires: A big assumption that there is only one salt dir in a profile ' %userprofile% be defined and set to user's win profile dir ' "mozilla -CreateProfile default" command already run ' Effects: Returns one path to where prefs.js should be overwritten ' This path includes the mozilla random salt dir Dim sProfile Dim oSubdirs ' File listing of default profile directory Dim oSaltDirs ' Salt dir object Dim sSalt ' Salt directory name Dim oShell Dim oDir Set oShell = CreateObject("Wscript.shell") Set oDir = CreateObject("Scripting.FileSystemObject") ' Find value of userprofile env var sProfile = oShell.ExpandEnvironmentStrings("%APPDATA%") sProfile = sProfile & "\Mozilla\Profiles\default\" on error resume next set oSubdirs = oDir.GetFolder(sProfile) if oSubdirs = Empty then GetDest = "notfound" else for each oSaltdirs in oSubdirs.Subfolders sSalt = oSaltdirs.Name ' There really should be only one. If not, heh! Next sProfile = sProfile & sSalt & "\prefs.js" GetDest = sProfile end if Set oShell = Nothing Set oDir = Nothing End Function
Ken, what you propose is fine if you're using roaming profiles, or if you only need access from a single location. If, however, you store your Mozilla profile in a network-accessible location like your home directory (ie h:\mozilla), you need to point %APPDATA%\Mozilla\registry.dat to that location (of course, resistry.dat is not text-editable). Being able to specify the Mozilla profile directly in registry.dat will allow network users to 'roam' to different machines and maintain their Mozilla profile without having to use Windows' Roaming Profiles feature. Apparently, the linux equivalent of registry.dat is currently text-editable, so this is not a problem on that platform. Alternatively, if the profilemanager would have an option to not 'salt', then we could leave registry.dat in its un-editable state yet achieve the same result by specifying the 'correct' mozilla profile directory when its created.
I agree, I was just trying to be helpful. There is another bug relating somewhat to this, and that is bug 110832 -- which was marked a duplicate of bug 162025 even though, IMO, bug 110832 has a better description of the problem. And that problem is the lack of support for UNC paths. This is a real killer if your group policies redirect %appdata% to a UNC share (and mapping to a network drive letter is not possible since appdata gets defined during logon before any drives are mapped). It seems registry.dat must reside in %appdata% and moving %appdata% is not an option due to UNC issue. Perhaps a HKLM registry key that could point to where to find profiles would at least allow the entire tree to move elsewhere (outside the user profile, like to their home directory) which would help work around the lack of support of UNC paths. Netscape 4.x found its profile location this way and we used that to move the profile tree. While this bug is marked enhancement and the others are critical, all together they create a hostile environment to rolling out any Mozilla-based product in a large environment. We're trying where I work and have had some limited success with some scripts run at logon. Whenever we have something workable and tested, we intend to publish the scripts in hopes it will help others. Also, having registry.dat be a text or XML file would go a long way in helping us as well...
> Also, having registry.dat be a text or XML file would go a long way in helping us as well... See bug 174522. The other bug which would make salting less of a headache is bug 137006. That will allow you to move the profile dir from place to place without it having to have the same absolute path (which includes the salt)
it would help if we had a -CreateProfile which *just* created a profile... currently you can do: -CreateProfile "somename /some/path" and it'll create and use that profile. I'd prefer: -Create /somepath -Profile Somename this allows: mozilla -Create "c:\documents and things\mozilla\junk" -Profile Test where Create would mean create a profile and don't launch.
*** Bug 178873 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2beta → mozilla1.3beta
I probably should stay quiet, but having read through this and most of the original bug #56002, I'm a bit confused. As far as I can tell, the only place where files are put without user intervention is the cache directory, not to the profile directory as a whole. At least, that's the only attack I've seen mentioned. Would a solution to this problem be to salt the cache dir only, instead of the entire profile directory? Or is there some other attack?
Historically, there have also been attacks against the prefs.js file and the cookies file, to name just a few. Passwords and certificates are stored in the profile directory too; the salting provides an extra layer of protection for those too.
*** Bug 185564 has been marked as a duplicate of this bug. ***
I'd like to have this salting issue resolved soon as well. I work at a public library and our public workstation upgrade to Mozilla has been stalled because of the difficulty in supporting *many* computers with different salted directory names. I'd like to see an option during the installation process asking to use salted or specified (with a browse option) directory names. Another option would be the use of a switch when starting the installation process that would allow you to specify predefined directory name.
Let's worry about getting rid of absolute paths in profiles, which is the reason why salting is a problem, in 1.4.
Target Milestone: mozilla1.3beta → Future
I agree that fixing the absolute path problem should be first priority, but is there really no hope for getting the existing patch in as an optional behavior for people who need it? This is one of the top two or three issues that I get beat up for when sysadmin types find out I'm involved with mozilla. Can you clarify the problem with the existing patch, so I can at least pass that along to people who ask? (Aside from bitrot.)
OK, akkana. I just took another look at the patch and liked it better than I remembered. As a temporary measure, I don't see any harm in it.
Target Milestone: Future → mozilla1.4alpha
Attached patch fresher patch — — Splinter Review
Same as attachment 103096 [details] [diff] [review] with 2 things fixed: an instance of NS_NAMED_LITERAL_STRING in global scope. new code uses nsIPromptService.alert instead of window.alert. Tested again, works great.
Attachment #103096 - Attachment is obsolete: true
Attachment #116252 - Flags: superreview?(alecf)
Attachment #116252 - Flags: review?(akkana)
Comment on attachment 116252 [details] [diff] [review] fresher patch r=akkana Builds and works on linux. I have to mention the >80 character lines in newProfile1_2.js and nsProfile.cpp, but it's your module and your choice whether to shorten them. >+ >+ // and that the page is valid >+ if (!wizardManager.WSM.PageIsValid()) >+ return; Does this end up calling the new validate()? I'm not familiar with wizardManager methods. >+ // XXX This used to be getter_Copies(oldLeafName). Check ownership! >+ rv = aDir->GetLeafName(oldLeafName); Have you checked? I think it's okay, but please double-check. >- NS_ENSURE_ARG_POINTER(profileName); No longer needed? >+ // Make profile directory unique only when the user > // decides to not use an already existing profile directory >+ if (!useExistingDir) I might have been misunderstanding the logic, but I couldn't seem to get this to work -- I tried creating a profile named "default" with a directory of ~/.mozilla/foobar, and it created ~/.mozilla/foobar/default-fxv0maln (I expected ~/.mozilla/foobar/default or ~/.mozilla/foobar). That's not a big deal, since that's a minor part of this patch and I'm probably just misunderstanding the intent of the comment. None of these comments/questions block the review -- it looks good!
Attachment #116252 - Flags: review?(akkana) → review+
Comment on attachment 116252 [details] [diff] [review] fresher patch + // Append profile name. This prevents people from choosing some important directory + // as their profile directory and then deleting it when they delete the profile. + profileDir->Append(nsAutoString(aProfileName)); use nsDependentString here I'm not so keen on only salting the default directory though! I don't believe that it is "random enough" - for instance, what if I use "alecf" as a login to a lot of web sites, and one of those web sites just guesses that my profile directory is "alecf" That defeats the purpose of this whole thing on all profiles other than the default. Besides, is "default" localizable in any way? In any case, I'm fine with being able to override it, but I don't understand this particular requirement w.r.t. "default" holding my sr= until we hear word. I'd like to hear perhaps from mstoltz on this.
looking back over the bug, I see that in fact mitch is ok with this. But I must ask again.. because I really feel like I would name my extra directory "alecf" and that I use that all over, and that that string appears elsewhere on the disk. What if its the name of your machine, or something similarly guessable. If I'm an attacker is it really that much work to make a few guesses based on information I might know about the user?
Okay, so you want to view the name of the profile directory as some sort of low grade password. Fine - just tell that much to the user! Ask him whether he wants to select a name to the profile directory himself, and tell him that this name is a "low grade password" (i.e., he should not use something easily guessable, but he should not re-use a valuable password - like his ATM PIN - either because, after all, this will be a directory name).
Comment on attachment 116252 [details] [diff] [review] fresher patch ok, my condition for reviewing this is to have mitch r= this... mitch, akkana has done the bulk of the reviewing here, but please see comment 82 and comment 83 I guess I don't see a good reason to make all non-primary profiles unsafe just because a few people want to be able to hack in their profile directory.
Attachment #116252 - Flags: review+ → review?(mstoltz)
Comment on attachment 116252 [details] [diff] [review] fresher patch removing from my review queue - please re-add me when mitch reviews.
Attachment #116252 - Flags: superreview?(alecf)
How about this: always salt the default profile. Salt non-default profiles if they're placed in the normal profile directory, but don't salt them if they're put somewhere else. As I said in comment 10, I think that saving the profile to a nonstandard location is protection enough. I agree with Alec that since a non-default profile is likely to be named with an easy-to-find username, it will not be sufficient protection against an attack directed at an individual (it would foil attacks directed at random visitors to a site). I'm not qualified to r= this patch, because I don't know this area of the code very well, but I would like to see salting of non-default names if they're in the default directory; Alec can r= the actual patch.
Attachment #116252 - Flags: review?(mstoltz) → review?(alecf)
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Comment on attachment 116252 [details] [diff] [review] fresher patch ok, since this doesn't do what mitch suggested, I'll cancel the review request for now...
Attachment #116252 - Flags: review?(alecf)
What mitch suggested in comment 87 was what my original patch did, back around comment 16, but then somebody didn't like that... I love it :-)
I don't care if we add a salted subdir or append salt to the profile name; do whatever makes it easier to use.
> I don't care if we add a salted subdir or append salt to the profile name; > do whatever makes it easier to use. If it were easier to use as-is this bug wouldn't exist. <grin> The point here is to remove the existing salting (from the subdir and the profile name), because *any* randomness makes it harder to use for people who want to rely on scripting. I'm sure I'm not saying anything that's hasn't already been said - I just wanted to insert a reality check that, as far as this bug is concerned, salting is a bad thing. The only question is under which conditions it's "okay" to over-ride the existing behaviour. I feel like we've gone in a big circle here...
Nominating for 1.4b because it blocks mass adoption by corporations. Seems that there is an overprotection which isn't really justified in the context under consideration. With a disclaimer, users will share the blame (comment 84). Looking at it from a real life (tm) perspective, most people will just use the default directory which will be salted, with other goodies, etc. It is with corporations that the difficulty lies. And with corporations, what do we have? Sysadmins who know/understand the risks, proxies, etc. In my case for example, sysadmins in our department are so far refusing to settle on Nav7 as the default mailer/browser due to this _single_ bug which prevents preparing profiles for users (same as comment 64 and comment 66). For admins who are willing and _able_ to "control" things and deal with the consequences (whatever that might be) the salt seems to be taking a customizing power away from them. They know/understand all the prose about the salt, etc, but for the sake of mass deployment, they wish to be able to override it. Please give the fix a try in the next release, with the caveat that it can always be reverted back if testing on the terrain shows that the risks indeed outweigh the benefits.
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b-
Henrik Gemal just posted an excellent workaround to this problem in a blog entry: http://gemal.dk/archives/000178.html
This whole thing is ridiculous to say the least IMHO. It was stated early in the comments that "salting" the directory is a security issue. Bah humbug, if you believe that then I have the proverbial land in Florida or the Brooklyn Bridge for sale. The point is that IF somebody can hack into your computer, it makes no difference WHAT the directoy is named, SLT or not. Once you're in you're in and guessing isn't necessary after that. Hacking in to an unprotected port 137 or 139 is a piece of cake and likewise for finding the profile directory and related info therein. Communicator profile directories weren't "salted". Was there ever a security breach of immense proportions to now warrant this? Just UNsalt and be done with it.
*** Bug 223251 has been marked as a duplicate of this bug. ***
I have been watching this bug for well over a year now. I have found ways around this salting "feature" (mainly hexediting the registry.dat file) but none that gave me a warm enough feeling to go ahead and deploy Mozilla to my organization. So we limp along with Netscaoe 4.x as our default e-mail client and it's pretty much now useless web browser. I have to tell folks to use IE as a workaround to problems in the older Netscape browser. I would think that Mozilla.org would prefer to have Mozilla/Firebird/Thunderbird deployed in schools, libraries, government agencies or small to large corporations. This issue of salted profile names prevents the easy deployment and management of Mozilla in any enviroment larger than a handful of PC's. The folks that have commented in this thread know how Mozzila works, know why there is a perceived "need" for salted directories, and are asking for some simple workaround to turning off salting so they can move on and deploy Mozilla in their businesses. Is that such a bad thing? Go ahead and leave directory salting on by default, don't worry any more about confusing the user. In my opinion in it's current state is is already confusing but so be it. If you want to hide it from the masses to lessen confusion, just make a command line option to turn off salting. We're not asking for a new CCK here. Please just give us sysadmins and network administrators the ability to use our current tools and knowledge so we can deploy Mozilla to an unsalted directory of our choosing.
Salted profiles are a completely ridiculous security measure. The salt can be easilly guessed with no more than 1 line of code from a malicious script, and it is really annoying when it comes to backup and scripted user profile configuration. I've read all the complaints in other bugs about this issue and I cannot understand why this thing still exists.
Please post your "one line" code script as a security bug.
Add mine to the chorus of voices asking for salted directories to be optionally disable-able during Profile Creation.
(In reply to comment #100) > Add mine to the chorus of voices asking for salted directories to be optionally > disable-able during Profile Creation. If you want to be "added to the chorus" then VOTE for the bug, not as a reply.
I suggest closing as the latest versions do NOT append the salt directory, when the profile is created from the command line. OK, I would personally prefer to be able to disable it from the GUI as well, but I guess that is an OK solution...
one of the best references/recommendations I've found for encouraging financial institutions to support firefox is located at bankers on-line web site http://www.bankersonline.com/security/security_browserthreat070204.html It was written in 2004 during the download.ject attack, but much of it still applies today. This is a good link to send when contacting banks.
QA Contact: agracebush → profile-manager-backend
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: