Hi,
On Thu, 2009-06-18 at 21:11 +0100, Richard W.M. Jones wrote:
> On Thu, Jun 18, 2009 at 03:02:53PM -0400, Matthias Clasen wrote:
> > On Thu, 2009-06-18 at 19:09 +0100, Richard W.M. Jones wrote:
> > > Can the malware inject code into the process which gained the
> > > authentication (eg. using ptrace)?
> >
> > Once you have malware running in your session, there's probably more
> > important stuff to worry about, like all your data in ~/.firefox...
>
> Right, but this is about privilege escalation (malware trying to gain
> root). However I agree that it's bad enough if you have any malware
> in your session.
>
> I'm only interested BTW. I'm not saying this is a real exploit :-)
As others have said, if you have malware in your session then you've
basically lost already.
The observation to make here is that for truly dangerous stuff, such as
installing unsigned software (PackageKit) or running programs as root
(pkexec), you _always_ use one-shot authorizations. There is even a
facility to customize what is shown to the user in a way that is not
spoofable [1].
But for e.g. applications where you repeatedly need to continuously do
operations over and over again, such as a disk utility app for example,
it's not really convenient having to type in your password over and over
again. As noted in many many places about both usability and security,
authentication dialogs are, in general, bad - they don't really add any
real security, they confuse users and they disrupt workflows.
So for applications where the authorization to do stuff is kept (for a
limited time and only limited to the process doing it), sure, malicious
code running as the same uid can inject code and take advantage of that
authorization. It doesn't even need to use ptrace, there's a lot of
other well-known ways to inject code. Including, but not limited to
taking advantage of the windowing system (e.g. X11) and the
accessibility framework.
But the point is really that said malicious code can't do a lot of harm.
At worst it can manage your networks, update installed packages with
newer signed versions and, if the user happens to run the disk utility
app, format some disks that are not already mounted and maybe change the
time zone. Not very exciting, compared to some much higher value targets
in e.g. ~/.firefox or ~/.evolution.
Of course, if the user wanted, he could configure PolicyKit so it always
prompts for authentication whenever the user requests services from a
Mechanism. Or you can use the existing nullbackend (shipped with polkit)
to always deny service (it's what you want to use for servers). But then
you turned a relatively good desktop user experience into a horrible
one. Ie. not worth the effort. Unless maybe you are the DoD (and that's
exactly why PolicyKit is pluggable so orgs/sites/etc can define their
own authorization policy.)
Anyway, the goal of PolicyKit isn't to fix the "cope with malware in
your session" problem. That problem is much much harder to fix and it
requires us to depart from the model where the whole user session is a
single security context.
Hope this clarifies.
David
[1] : except of course that right now the authentication agent runs in
your user session. This means it is susceptible to the same attacks as
anything else in the session including ptrace and xspy. So you can
easily inject code into this process to capture passwords or spoof
dialogs.
Anyway, the way we want to solve this is to add a "secure" desktop.
Whenever we have the need to prompt the user for a password, we bring up
the "secure desktop". This would be a completely different session using
a separate X server and with only well-known and trusted programs
running in it. We'd run, ideally, all password prompts in this session.
User-experience-wise the user won't notice this implementation detail
since we can composite it to run on top of the normal desktop. We'd want
to make it hard to spoof though - there's a couple of well-known ways to
do this as well (make it show something your sessions can't know, make
it do something your session can't do (require you press ctrl+alt+del)).
Users of this "secure desktop" would include
- PolicyKit Authentication Agents
- Screensaver
- GVfs
- the gvfs backends needing the passwords don't use UI so it is
possible to secure these programs so you can't get to them via
ptrace
- Other things needing passwords
- IM programs such as Empathy
- ...
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
