Bug 136341

All the config tools user usermode to prompt for this. Reassigning.

Which version of usermode are you using? It works for me with
usermode-1.74-1.

usermode-1.74-1

What do you mean by "it works for you"?

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.

Same here, but there is no way to verify that the window or prompt
asking for the password is trusted.

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"?

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.

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?

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
ctrl-alt-delete.

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.

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.

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
dialog.

It's tempting to close the bug, but it won't fix the problem.
What to do?

"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."

then:

"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/

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 "#".

-AB

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.

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.

Thanks,
Jindrich

Yikes - don't close my bug though!

tcsh root prompt is just a default configuration value (BTW, changed in rawhide
initscripts).


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
  windows.


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.

Thanks Miloslav.

I noticed that this paper seems relevant to this bug:
 http://www.sims.berkeley.edu/~rachna/papers/securityskins.pdf

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!

Moved to devel; thanks.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.

Closing bug due to lack of interest from Red Hat.

(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. :)

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.