353203 - User's Firefox process runs as root (if root is running Firefox)

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Simon Shapiro]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.0.7) Gecko/20060918 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.0.7) Gecko/20060918 Firefox/1.5.0.7

Scenario:

*  As root, start firefox, by typing (to the shell :-) firefox

*  As regular user, start firefox too.  Again, by typing firefox.

*  The user session actually will run the root's process, as root,
   This is visible if root has a different theme,  Also the URL
   file:///etc/master.passwd will show the contents of the file
   (on _both_ windows)

*  I am not sure if this is a feature, but imagine an administrator managing
   a database, router, CUPS, etc. and then joe comes along...

Reproducible: Always

Steps to Reproduce:
1.  See the details above.
2.  It is really simple.
3.  Really!

Actual Results:  
1.  If one user runs on a machine, another user gets their pribvileges,
    settings, etc.

Expected Results:  
Each Unix unser runs in a separate environment, without the ability to share the
execution of the same process.

Each user should fire their own process, and have no sharing of identity, permissions, etc.

Comment 1

[Jesse Ruderman]

Dup of bug 247412?

Comment 2

[Simon Shapiro]

*  Yes, it is similar to 247412, I searched before posting, but having more than
   10,000 bug reports in between makes my not feel so bad.

*  MHO is that the treatment of 247412 was less than deeply contemplative;

*  In particular, comment 15m which sort of closes that report, has numerous 
   errors and omissions;

*  I obtain privileges while the different users are there via login, not su.
   Further, the new user wipes out the environment (except DISPLAY :-)

*  The privileges apply not only to the display (which other than school pranks
   may have little value to common humans), but to the filesystem itself. Root
   is root, there is no "root only IRT to X11 Display". I confirmed it, by 
   reading and writing /etc/master.passwd.

*  It is interesting to observe that the much maligned Windows understands the
   concept of security better than Unix types demonstrate here:
   Security is not evaluated by what violation we can get away with because
   our understanding does not encompass exploiting the defect yet.
   Windows behaves correctly:  A process owned by one user (particularly a
   privileged one!) cannot grant its privileges to another, unless this is
   done by design and explicitly.

*  The Orange book, for example prohibits cutting and pasting amoung 
   incompetible security levels.  Here we allow a program to actually run
   under unadvertised permissions, and we still call it "secure"??

*  I fail to see the point behind this "attaching" anyway;  Is it a 
   demonstration of prowess, a new concept in software engineering?
   From ystem resources, the savings are minimal, as the Unix kernel
   will share all the RO pages of a program and yet partition off process
   specific data (which really should be partitioned anyway.

*  The most annoying aspect of any/all Mozilla, frommy User perch, are these
   fangled profiles, and the mutex on them.  like the profile concept;
   Here is a theme/modules/preferences combination I like to use for certain
   class of work.  Giv3e it a name, and allow me to select it at startup
   time.

   But why do I have to suffer restriction to only one instance of this profile?
   Inessense youtake the File->NewWindow feature and make it mandatory across
   time, user ID, etc.  If it is on the same display, it is the same instance?!

Thanx for your precious time.

Simon

Comment 3

[Jesse Ruderman]

I don't know enough about unix permissions and X to know if this is a valid bug report.  Blizzard, do you?

Comment 4

[timeless]

i'd like to declassify this, from my perspective it's a known implementation element.

yes people don't like it, but no, it's not going to be fixed if it remains confidential.

Comment 5

[Akkana Peck]

It does sound like a valid bug.

It looks like XRemoteClient.cpp is already trying to check for this (but evidently the check isn't working right):
    // Check to see if it has the user atom on that window.  If there
    // is then we need to make sure that it matches what we have.
and then it gets username and compares it to mMozUserAtom.

It does a similar check for mMozProfileAtom, but I suppose the first default profile has the same name when root makes one as it did when the user made theirs?

Anybody here who's more familiar with the X remote code? Is it possible firefox isn't setting the mMozUserAtom properly, like setting it to the real uid instead of the effective uid?

Comment 6

[Simon Shapiro]

From the same machine:

*  Almost all users have a profile user-default (or some such), so comapring
   profile name is less than useful.

*  From a remote machine, there will be a difference between streight X,
   SSH tunnel, etc.

*  If I am on machine A, telneting (ssh, etc.) to machine B, and on machine B
   I do:  export DISPLAY=machineA.do.main:0.0; firefox,
   What I expect to happen is for machine B to fire a firefox process, using
   machine A as display/keyboard/mouse/speakers/icecream-dispenser/etc.

   *  Unix and X will take care of the permissions, etc.

*  What I get instead, is Firefox on machineA forking a new window, but running
   on machineA!  If I download, it saves on A, if the user ID is different it
   maters not.

*  General Observation;  All this extra, explicit behavior is totally 
   un-necessary. It saves (if that at all) about 1-2 kilobytes of memory at the
   expense of breaking all sorts of expected behavior.

*  Instead, (at least for Unix), rip all this out and have firefox/mozilla
   whatever, simply run in its process, on its machine.  The Unix, TCP/IP, 
   X, SSH, SSL, etc. will take care of running things correctly.

*  Oh, when I was still working, my signature said "unwritten code has no
   bugs and executes at the speed of mouth"  Think about it.

Simon

Oh, can I make this bug public?  You will be amazed how disinfecting sunlight
is :-)  It also clarifies your vision real good, real quick.

Comment 7

[Benjamin Smedberg]

This is a known implementation detail of the way xremote works. Because we cannot have two Firefox processes using the same profile directory, whenever firefox is launched we look for an existing instance (using X) and execute remotely in that process. Getting rid of this behavior in the normal case of the same user running firefox twice is not an option.

To fix this bug, we should at least indicate which user the X window belongs to, and perhaps only accept XRemote invocations from that user. I'm not sure how to do that.

Comment 8

[Akkana Peck]

They aren't actually running from the same profile directory, are they? Shouldn't one be running from a profile located in /root, and the other in /home/username?

If they're running from the same profile dir (and hence it's seeing a lock file and using xremote), maybe that's what should be fixed: when run from su (ruid != euid), perhaps it should look for the profile in the effective UID's homedir rather than $HOME. And that would be a lot easier to fix than patching the xremote protocol.

Comment 9

[Benjamin Smedberg]

No, they're not using the same profile dir. But remoting and profile locking are entirely separate activities.

Comment 10

[Regis R.]

Hi, I vote for this bug.
I've just discovered this "feature" while launching firefox via the crontab which let LOGNAME empty.

>A process owned by one user (particularly a
   privileged one!) cannot grant its privileges to another, unless this is
   done by design and explicitly.

I agree with this, especially on the explicitly condition.
Firefox is not known as a server, so shouldn't act as a server.
Which percentage of users know this feature ?

Even if I'm alone on my PC, why a programm i launch from a restricted user should be able to read and write the "normal" user's profile and datas ?

Comment 11

[bugreporter]

[lastest firefox|Windows7]

Hi,
discovering the same design flaw today I searched the database and discovered that it has been an issue for about 6 years now!
Pardon that, but it is complete ignorant to change a normal os behaviour even without any notice to the user! If a use runas, i want to runas! and not have just another browser window. the -no-remote is no excuse unless it would be the default option!
Please rethink/rework/... and fix this!

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Running Firefox as root in a non-root session is not supported, and as of bug 1323302 it should be relatively difficult to do accidentally.  It's still technically possible (and the --new-instance and --no-remote flags are available to control remoting), but X11's permissive security model means one should basically treat the user account as if it had passwordless sudo in that case.

(Historical note: for an explanation of why the username check in XRemoteClient didn't seem to work, see bug 247412 comment #15; today it seems to vary by OS whether su without -l resets $LOGNAME, and sudo resets it by default.)

Also, it probably doesn't matter anymore, but:
Comment #10 might be fixed in bug 1345413, falling back to getpwuid(geteuid()) if $LOGNAME is unset.
Comment #11 should be a separate bug if it isn't already; there's different code for this functionality on Windows vs. X11.