Closed Bug 97180 Opened 23 years ago Closed 13 years ago

Make profile directory salting more user-friendly

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:
Future

People

(Reporter: security-bugs, Unassigned)

References

Details

There have been a lot of complaints about the xxx.slt directory that's added
underneath the user profile directory to make the path unguessable by an
attacker. Some of these complaints have been addressed by other bugs, but more
generally, the salting is ugly and it's a pain for people who like to muck
around with their profile directory directly. So, let's use this bug to come up
with alternatives. One possibility is to use some sort of salting only for the
default profile, and trust that profile names other than "default" will be
sufficiently unguessable. This may not be true, especially if the attacker can
get the user's email address,  or another bit of ID which may correspond to the
profile name. I'd like to hear people weigh in on the security of this
alternative, or to suggest other alternatives. Let's use this bug to brainstorm.
Please do not post comments like "salting bugs me, let's get rid of it" to this
bug. I believe salting provides a significant security benefit, so let's work to
make it friendlier without getting rid of it.
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Here are some suggestions:
1)  When the profile manager first comes up, provide a text input that shows
what the new salted directory name will be, but allow the user to edit it.  By
default, novice users are probably going to just OK it, while more advanced
users can change that name to suit their wishes.

2) If we can assume long filename support on all platforms (I don't know if we
can), then use the profile name, and add salting to that name itself.  One of
the things I don't like about the current method is the extra directory level
under <profile name>, since the <profile name> directory itself doesn't hold
anything else.  With this proposal, you would end up with <profile name-salted
addition> as the directory.

3) At the least, make it easier to copy settings from one profile to another. 
Say, if I wanted to duplicate my profile on another computer.  IIRC, the salted
directory name is saved in a number of prefs right now, making it very hard to
move profiles around without editing a lot of prefs.
> This may not be true, especially if the attacker can get the user's email
> address,  or another bit of ID which may correspond to the profile name.

In this case it would be a directed attack to a single person/a single profile.
I guess mozilla can't do that much about an individual attack anyway. But noone
else would be affected by an individual attack, and a general attack would be
avoided by salting the default profile.
Target Milestone: mozilla1.0 → mozilla0.9.9
Less important bugs retargeted to 0.9.9
Target Milestone: mozilla0.9.9 → Future
I would suggest that the current method of salting by left the
way it is.  Ie., using a subfolder called "random_garbage.slt".

However, I would suggest that the use of the salting be made
entirely optional.  A simple checkbox item in Profile Manager
"Salt user profiles with random garbage" would do the job.
Put a little "What is salting?" button there too, taking 
users to the relevant section of the help file.

It is highly dubious that salting has any security value, but
if you are a network admin trying to update bookmarks and 
address books for hundreds of users, then that random garbage
is a pain in the butt.   Hackers are mostly kids who delight
in working around minor nuisances like the salting.  Network
admins, however, usually have better things to do with their
time.
Has there been any activity on this issue in the past year or so?
My organization has outgrown Netscape 4.xx some time ago, and I won't move to
IE. Mozilla is good enough for distribution here now, but this 'salting'
prevents me from distributing it effectively. Like the last comment, all I want
is the ability to turn it off. I think there are alot of sysadmins out there who
will be stymied by this 'feature'...
If its too much work to modify the GUI of the Profile Manager, how about letting
us modify a pref file to turn it off?
Comment #6 : we performed a departmental deployment (120 machines, 200 users) of
NS7 two weeks ago.
1. I made a local one-shot test install, then modified the "registry.dat" with a
hex editor, replacing the default random salted directory with a network folder
and padding with ASCII zero's.
2. After installing NS7 on the workstations, each user's registry.dat is
replaced with the modified one.

Choosing a network profile folder has the added advantage of :
- profile roaming ;
- user privacy (the network drive is mapped to each user's personal network
directory).

HTH.
*** Bug 181682 has been marked as a duplicate of this bug. ***
One way to make this completely invisible to the user is to have Mozilla auto-
detect any existing salted directories before creating one. It seems to do 
detect it in some cases (e.g. when you delete a profile without touching the 
files), but not all the time (e.g. when you create a new profile to be linked 
to an existing profile directory for another Mozilla installation.)

This issue could be filed as a seperate bug if desired, but it is worth noting 
here.  

This is a total killer for backup and restore. Lets say my old profile is

.mozilla/rjn/xyz123.slt/

I then do a new install (upgrade mozilla, move to new pc, replace HDD, whatever)
and create another profile: .mozilla/rjn/abc456.slt/

Even if the rjn bit is the same, I am in trouble, as there is no way to copy my
old data into that profile and have it recognise where the mail is. 

If I do:
    rm .mozilla/rjn/abc456.slt
    mv backup/.mozilla/xyz123.slt .mozilla/rjn/

then this should fix everything. BUT mozilla then throws an error and won't
start the rjn profile - it can't find abc456.slt and hasn't the sense to try
using xyz123 instead.. THIS needs to be changed.

A workaround on linux is to do:

     rm -rf .mozilla/rjn/abc456.slt
     cp -r  backup/.mozilla/xyz123.slt/ .mozilla/rjn/
     cd  .mozilla/rjn
     ln -s xyz123.slt abc456.slt

(I've discussed this more in my comments on Bug 63389)
The real problem is that, on platforms other than Mac, many prefs are full
paths, and those paths contain the xxxxxxxx.slt string. Renaming, symlinking,
etc. can't help with that. Using relative paths makes salting a non-issue WRT
moving and backing up profiles. See bug 137006.
Reassigning to default owner.
Assignee: mstoltz → ccarlen
Status: ASSIGNED → NEW
See what I did to workaround this bug in bug 31732 comment 23
Maybe it would be easy enough to add a commandline option -profiledir, so that
salting is used normally (so no concerns for security like in comment 1) but not
when a profile directory is specified on the commandline (so avoiding the
contortions I had to resort to).
Comment number 13 would be an ideal solution to this problem. It shouldn't be
very hard to implement either; read a commandline-option and add a simple
if-statement. If someone with knowledge of the sourcecode could point us in the
right direction we can take a shot at it.
create profiledir with .slt:
http://gemal.dk/archives/000178.html
I think there should certainly be an option for disabling this, or bypassing it.
 Maybe it should be a profile option, whether or not to do the salting?  For my
systems, at least, it is never anything but an additional layer of inconvenience.

Frankly, once someone's got enough access to be trying to scribble files in my
home directory, I've already lost; they don't need to find my mozilla profile,
and if they need to, they can find it easily enough by grabbing the one
directory within my profile directory.  It might, potentially, make sense to use
salted names for the names of profile directories.  Having profile_name/salt is
silly, because you can always find the directory anyway.  However, on the whole,
this is probably one of those things which is of marginal use to most users, so
a way to turn it off is called for.
> Frankly, once someone's got enough access to be trying to scribble files in my
> home directory, I've already lost; they don't need to find my mozilla profile,
> and if they need to, they can find it easily enough by grabbing the one
> directory within my profile directory.

You're misunderstanding the reason for salting.  It's not to protect you from
someone who can already write to your entire HD, but to protect you from someone
who can write to some parts of your HD.  We have to salt because of bug 230606
(a local file loaded in the browser can read any other local file you can read),
which is present in all JS-supporting web browsers.

This is the same reason Mozilla has to disallow links to file: URLs, btw.
Assignee: ccarlen → nobody
Severity: minor → enhancement
QA Contact: ktrina → profile-manager-backend
The current Profile Manager allows you to give each new profile a name of your choice.  I believe that solves the problem and I recommend that this bug should be closed.
(In reply to comment #18)
> The current Profile Manager allows you to give each new profile a name of
> your choice.  I believe that solves the problem and I recommend that this
> bug should be closed.

agreed.  I couldn't find the bug that fixed this.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.