Closed Bug 59120 Opened 24 years ago Closed 12 years ago

No Option for Password Protecting Preferences

Categories

(SeaMonkey :: Preferences, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: brian, Assigned: samir_bugzilla)

Details

(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox])

It just occurred to me that there is no way to set a password that just protects 
the preferences part of mozilla.  This is a major problem for schools and other 
places that have computers made publically available.  At our school, we run a 
content filtering software through a proxy.   The problem is that students can 
bypass the filter by reseting the proxy prefs to direct connection to the 
Internet.  We have also had problems with students messing up settings in the 
preferences area.  I would really like to see this ability added.  I'm filing it 
as a bug (rather than an enhancement) because this is something that every 
browser should have.  Let's hit IE hard with this release.  Keep up the good 
work, and let me know if I can do anything to help with this project!
i think this would be handled in an enterprise version of the browser, yes?
paul/matt, either of you know who should get this in that case?
Why not put it in the base?  I'm sure there are more applications for this than 
just enterprise use.  Maybe parent's want to keep their kids for resetting 
certain things??  
confirming as an enhancement. still not sure who/which group should get this...
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
IMHO, I don't believe this enhancement should be delayed.  At the school's 
technology department we have students tampering with settings and disabling the 
filtering proxy.  The students can then engage in restricted activities.  This 
filtering system is used in numerous schools throughout Nebraska.  I believe 
password protection of the preferences dialog is a low risk/high benefit 
bug/enhancement.  Thank you!
Should the browser security general area get this?
this would prolly be dependent on bug 19184 --and maybe even bug 60466 [or, the
earlier version of the latter]. cc'ing gbush.
Depends on: 19184
I'd like to keep this moving if we could.  I really think this feature needs to
be included.  Could we target this mozilla1.0 or so?
Brian, if you're going to implement this yourself, or hire someone to do it, you 
can set it to any target you like. But bugs don't fix themselves, y'know.
OS: Windows 98 → All
Hardware: PC → All
Added help wanted keyword.  I'm afraid I'm not going to have time to do this. :(
Keywords: helpwanted
Nominating Mozilla1.0
Keywords: mozilla1.0
Offloading to mozilla1.1
Keywords: mozilla1.0mozilla1.1
Taking.
Assignee: matt → sgehani
Target Milestone: --- → mozilla1.1
See also bug 16489, `Password protection of profiles'.
i'm confused. are .cfg locked preferences really not good enough for you? (see 
netscape.com's 4.x documentation for more info. I've never used them since i'm 
not a coporation).

secondly, if you only implement a proxy as an option and then are shocked when 
your students realize they don't need to use it, you're the fools, not them. 
The proxy was designed for cases where users could not have direct access (it's 
part of the concept of proxying...), your border between the students and the 
net should drop most packets on the floor, forcing students to go through 
proxies that live in your DMZ.

Third, password protected profiles don't prevent pref changes, they prevent 
profile usage. Sorry, this isn't the goal here. Same problem w/ encrypted 
profiles.

Fourth, expecting users not to figure out how to create their own profiles is 
idiotic. If you indeed represent a school, then I encourage you to *learn* from 
your students, I know that my peers knew a lot more about what could and could 
not be done than the people who tried to control computer/internet usage.

Step 1 is of course to establish a real firewall that forces proxy usage.
Step 2 is to admit that you can't win all the time.
Part of this is accepting that unless the users have no writable space, they 
can duplicate whatever they need to do whatever it takes to get around whatever 
files you give them. [eg: You give them a profile on a readonly fs, they create 
a new one somewhere else. You give them a locked profile, they install a new 
browser.]

I don't think that there is a feature we can give you beyond the ones we've 
already provided that will actually help.

That asside, the Kiosk bugs (Bug 3341 and others that 
are mentioned, linked, or dependent) are probably your best bet.

There are lots of problems w/ schools, some of them, in no particular order 
are:
* too little funds
* too much overhead
* too much belief that technology can save education
* too many people who don't think before trying to do something (teach, setup 
networks, lock networks, buy equipment)

i'm clobbering the dependency because it's clear it wouldn't help the reporter. 
(i don't think we can help the reporter beyond what we've already done, and 
that should be clear from this comment, but that's unrelated.)
No longer depends on: 19184
Unless the prefs.js and other relevant files have write permission
denied at the operating-system level, there is NOTHING Mozilla can
do to prevent the prefs from being changed.  You can make it more
inconvenient by creating user stylesheets that display: none the
menu items for the Preferences panels, but there is readily available
documentation all over the web about how to edit prefs.js by hand,
and (especially in secondary schools, where a percentage of your 
users (and it only takes one) know computers about fifty times 
better than your IT staff) any reasonably determined user who knows 
how to use Google or Yahoo will find it in five minutes flat.  Given
motivation to do so, my mom could probably figure out how to do it. 
This is unfixable by Mozilla.  Remember, people don't want to edit
config files by hand; they don't like to do it, and in general
they won't, but they _can_ figure out how if motivated, and nothing
motivates them like somebody saying "you're not allowed to do this". 

That said, a school could use a locked-down operating system to
prevent changes to the prefs files (and other things), but Moz
doesn't attempt to write the prefs files until it's exited, so
allowing a temporary bypass.  Access to the prefs dialogs does
also need to be denied in these cases.  User stylesheets (which
must be also write protected at the OS level) will do this if
new-profile-creation is disabled -- which it effectively can
be if you have just one default profile and disallow access to
the commandline.  (Disallowing access to the command line is
necessary anyway; you need a custom X setup with no way to 
get to an terminal window of any kind, and only very limited 
applications, but that's inherent in such a setup.  You also
have to prevent physical access to the PC case, because if 
they can reboot it they can get to single-user mode...)

This is all WAY beyond the scope of anything Mozilla can be
expected to do, and if you don't do it, your users WILL be
able to change the prefs behind Mozilla's back, regardless 
of anything Mozilla does or does not facilitate.  

It is possible to make Mozilla prompt for a password before
popping up the prefs dialog, but that would be a placebo
only, nothing more.

Take the trouble to be secure, or don't, but let's not 
make believe.
retargeting
Target Milestone: mozilla1.1alpha → Future
could this be done by doing a simple test and preventing access to the prefs
dialog if the prefs.js file is readonly?
Product: Browser → Seamonkey
(In reply to comment #14)
> secondly, if you only implement a proxy as an option and then are shocked when 
> your students realize they don't need to use it, you're the fools, not them. 
> The proxy was designed for cases where users could not have direct access (it's 
> part of the concept of proxying...), your border between the students and the 
> net should drop most packets on the floor, forcing students to go through 
> proxies that live in your DMZ.

This is a good argument for a school, but not for a home user.

I am interested in password protecting my preferences dialog for my home
computer.  As Mozilla and Firefox is getting more popular more non-technical
parents, who can't set up a home network with a Linux box as a proxy server to
the Internet are going to want to use their ISP's content filtering solution.

Since most ISP's, like mine, want to allow unrestricted Internet access to most
of their users, they only offer a Proxy based solution for those who want
server-side (read free) content filtering.
(In reply to comment #15)

> This is all WAY beyond the scope of anything Mozilla can be
> expected to do, and if you don't do it, your users WILL be
> able to change the prefs behind Mozilla's back, regardless 
> of anything Mozilla does or does not facilitate.  
> 
> It is possible to make Mozilla prompt for a password before
> popping up the prefs dialog, but that would be a placebo
> only, nothing more.
> 
> Take the trouble to be secure, or don't, but let's not 
> make believe.


There is a way to treat the insecure file-system as a untrusted source and still
protect the preferences.

1. Require a password for the preferences dialog.
2. Hash that password and use it as the basis for an private key to encrypt a
copy of the preferences.
3. Compute an PubKey/PrivKey digitally signed hash of the plaintext preferences.
4. Thow the private key away.
5. Store the digitally signed hash of the preferences file and the public key in
plaintext.

You can now detect changes to the plaintext version of the preferences file by
comparing a has of the preferences file to the digitally signed hash sored by
the save operation.

If a change is detected, you can prompt for the user to enter the preferences
password to re-generate the private key and copy over the plaintext version of
the preferences file.

This is well within the scope of what Mozilla can do and it can use the existing
crypto libraries to do it.

The difficult part will be to generate a private key (in a public key - private
key cryptosystem) based on the password. But it is doable.
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
Ever confirmed: true
If preferences would be protected with password, what stops users from creating new profile and set needed preferences there? And if you protect profiles.ini file at OS level, why you can't do the same for prefs.js?
Propose WONTFIX this
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA/WONT?] → [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.