Bug 136341 - No way to verify "enter root password" window
No way to verify "enter root password" window
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2004-10-19 08:10 EDT by Need Real Name
Modified: 2017-07-14 16:00 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-14 15:41:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2004-10-19 08:10:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
When a program that requires the root password is run (e.g.
system-config-keyboard), a prompt is shown either in a new window, or
on the command line (if console).

There is not way to verify that the window or prompt asking for the
password is trusted.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Paul Nasrat 2004-10-19 09:19:08 EDT
All the config tools user usermode to prompt for this. Reassigning.
Comment 2 Jindrich Novy 2004-10-27 06:26:38 EDT
Which version of usermode are you using? It works for me with
Comment 3 Need Real Name 2004-10-27 06:38:25 EDT

What do you mean by "it works for you"?
Comment 4 Jindrich Novy 2004-10-27 07:50:11 EDT
When I launch system-config-keyboard as an ordinary user, I'm prompted
for password only in the graphical window, not in text mode in the
terminal I launched it from.
Comment 5 Need Real Name 2004-10-27 07:53:05 EDT
Same here, but there is no way to verify that the window or prompt
asking for the password is trusted.
Comment 6 Jindrich Novy 2004-10-27 08:44:46 EDT
I don't understand.

When I launch system-config-keyboard, userhelper is called and in case
it can run in graphics the window is displayed and no input is
required from the terminal. In pure text mode userhelper prompts you
for password in text mode. userhelper never asks the both ways.

What do you mean by "there is no way to verify that the window or prompt
asking for the password is trusted"?
Comment 7 Need Real Name 2004-10-27 08:47:40 EDT
I mean that there is no way to be sure that the window asking for my
root password should be asking for my root password.

If a window pops up asking for a password, I need a way of checking
that it's safe to give the password out.
Comment 8 Jindrich Novy 2004-10-27 10:50:23 EDT
In order to not to give root password to everyone who needs to
reconfigure system settings you should use the new feature of
usermode-1.74 that permits certain users, members of UGROUPS to
authenticate with their own passwords to grant access to the
system-config-* stuff. (see man 8 userhelper).

If a window pops up prompting you for root password and you haven't
launched any tool that requires authentication so it's a fake window.
I don't see any possibility how the window should look like to
distinguish it from some fake window. Any suggestions?
Comment 9 Need Real Name 2004-10-27 11:17:52 EDT
Without thinking too hard, the best way of doing this simply seems to
be to provide a window decoration that only a superuser-owned (or
specific user-owned) window can have.

For example, it might have a red border.

I realise there are plenty gotchas for this (full screen bitmaps,
etc). I expect this might be a case of "wait until an explioit
appears, then fix it in a hurry".

Microsoft's answer, which works with nothing but login, is

Not having a good answer doesn't mean this shouldn't be fixed though.
"Making sure that something that asks for a password is what it says
it is" seems to be a pretty basic requirement.

Perhaps the new usermode features (and the stateless Linux project)
will obsolete this bug - if you get asked for a password, you know
something is wrong.
Comment 10 Barry K. Nathan 2004-10-27 11:51:42 EDT
The Linux kernel has SAK (see Documentation/SAK.txt in the kernel
source code), but as with the Control-Alt-Del for Windows, it too is
only for login.
Comment 11 Need Real Name 2004-11-15 07:23:57 EST
Thanks for this, but I'm not sure it helps.
I can't see how an app can be stopped from looking like an authentic password

It's tempting to close the bug, but it won't fix the problem.
What to do?
Comment 12 Need Real Name 2004-12-08 14:30:30 EST
"The need for an operating system trusted path mechanism was
highlighted by [67] which demonstrates the ease with which a trojan
horse applet can capture credit card numbers, PIN numbers or passwords
by perfectly emulating a window system dialog box."


"The proposed solution was an ad hoc user-level trusted path mechanism
which required a user to customize his dialog box with a complicated
graphical pattern. This solution is not adequate as it only increases
the sophistication required in the trojan horse."
 -- http://www.nsa.gov/selinux/papers/inevitability/
Comment 15 AB 2005-01-27 15:32:33 EST
I have an additional issue with usermode that stems from the terminal 
screen.  With FC3, you are in tcsh usermode and then "su" for 
superuser mode.  Normally, the prompt (after authentication) changes 
from "$" to "#", but mine does not (although I now have root 
privileges.  Here's a copy of my terminal output line-by-line:

[ab@testbed ~]$ su
Password: (entered the password)
Note: The password is accepted and prompt returns as follows.
[ab@testbed ab]$

I have checked and know have root privileges in su mode but the 
terminal prompt does not indicate a "#".

Comment 16 Need Real Name 2005-03-08 10:08:20 EST
I think that would be a separate bug - probably with security
severity, since you can't rely on the system correctly telling you
whether you're logged in as root.
Comment 17 Jindrich Novy 2005-03-08 11:10:08 EST
Yes, please file a new bug related to this issue. Note that su is not a part of
usermode and I don't see anything where usermode is affected. It looks more like
tcsh bug to me since su is not called via userhelper. The security severity is
quite suitable for this in my opinion.

Comment 18 Need Real Name 2005-03-08 12:06:26 EST
Yikes - don't close my bug though!
Comment 19 Miloslav Trmač 2005-03-08 15:05:56 EST
tcsh root prompt is just a default configuration value (BTW, changed in rawhide

As for the original issue,
- the userhelper window is run _as the invoking user_, not as root (to avoid
  the possibility of exploiting possible toolkit bugs in consolehelper to gain
  root privileges); it is no different from any other window security-wise, so
  there is no criterion that would allow distinguishing the consolehelper
  window from any other.
- the window manager is also run as the original user and is subject to attacks
  by any other process running on the same machine (not necessarily by the
  original user) and by any application connected to the X server; why should
  it be trusted to mark the windows?
- AFAIK it is possible in X to draw over windows owned by other processes,
  so a rogue process could simply draw the special window borders over its

Yes, it is something that would be "nice" to "fix", but first we must have
a) a criterion for finding which processes / X clients are "trusted enough"
   (including the different requirements: root password, user's password,
   other user's password)
b) a mechanism for reliably checking this criterion
c) a way to reliably present the criterion to user
where "reliably" means "attacker has no way to duplicate this".

In the standard UNIX and X privilege design,
a) is non-trivial, probably impossible without changing the software
b) is impossible if you allow rogue processes running under your UID
c) is impossible if you allow rogue processes running under your UID
   or rogue X clients connected to your X server

Simply spoken, you have to trust the applications you are running; if you
don't trust them, don't run them, or at least run them with a different
user ID, and if they are using X, run them in Xnest.
Comment 20 Need Real Name 2005-05-29 16:30:25 EDT
Thanks Miloslav.

I noticed that this paper seems relevant to this bug:
Comment 21 Matthew Miller 2006-07-10 19:19:45 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 22 Matthew Miller 2006-07-11 14:10:48 EDT
Moved to devel; thanks.
Comment 23 Bug Zapper 2008-05-13 21:58:00 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 24 Bug Zapper 2009-06-09 17:59:34 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 25 Bug Zapper 2009-07-14 13:11:22 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 27 Need Real Name 2017-07-14 15:41:03 EDT
Closing bug due to lack of interest from Red Hat.
Comment 28 Matthew Miller 2017-07-14 15:45:32 EDT
(In reply to Need Real Name from comment #27)
> Closing bug due to lack of interest from Red Hat.

For what it's worth (and with some degree of irony to close now a bug from 2004...) it's possible that Wayland could finally offer a meaningful answer. But I agree that this bug probably isn't the place to find it. :)
Comment 29 Miloslav Trmač 2017-07-14 16:00:45 EDT
Even with Wayland the WM runs as the unprivileged user, doesn’t it? So it can still be attacked by other processes in the session.

This really needs application separation (per-app containers + portals, or something like that). That is also much closer to happening now than in 2004 as well :)

Wayland + isolated apps + trusted WM could give us a) and b) from comment#19; c) _still_ remains unsolved; presumably Wayland will allow full-screen games = give rogue applications the ability to spoof any dialog.

Anyway, if this will be fixed, it would be much more likely to be fixed for polkit (used more than userhelper nowadays, and the polkit agent can be a part of the trusted WM) than userhelper (with an ordinary unprivileged window prompting for the root password).  So let’s keep this closed.

Note You need to log in before you can comment on or make changes to this bug.