Malware protection?

[David Zeuthen]

Hi,

I've been on vacation so that's why I'm only replying now.

On Sat, 2009-11-21 at 15:22 +0100, memolus at googlemail.com wrote:
> >Ditto, actually, for any action for which the authorization is one-shot
> >and a system daemon is used. For example, a package manager UI wanting
> >to install an untrusted package would be safe if it uses a one-shot
> >authorization and the daemon requesting the authentication runs in
> >another security context.
> Wouldn't it be possible to inject code into the package manager UI?

Sure it would. But since the authentication dialog specifically mentions
the package name (and this name is provided by the pkg manager
_mechanism_, not the UI) any hijacked package manager UI code would, at
best, show the user a dialog for the undesired package to be installed.
Surely this package wouldn't be signed with any trusted keys so the text
in the dialog would scream "bloody murder".

> Why could there be no need to run the UI into another security
> context, too? I mean the UI, which is in the same SC as the malware,
> is authorized for a certain time frame to contact the daemon
> requesting the authorization. 

No, one-shot authorizations are _never_ kept - the authorization is only
valid once. One-shot authorizations were added precisely to avoid this
problem.

> Also I wonder, why you need an separate
> session for the authentication agent, 

Because otherwise malware could hijack the authentication dialog and
spoof the text in the dialog - thus tricking the user into install
things that are not desired.


> By the way, you don't have to ask the user for password. You can do it
> like the GNOME keyring or Windows UAC: Just serve "yes" and "no"
> buttons. They are as secure as password + secure attention key, if you
> use another security context, too. password + secure attention key is
> only needed, if you want to authorise as another user. It's already
> clear that the person sitting in front of the computer is the right
> person, because you are already logged in.

Yes, we could do no/yes in case the user password is requested. We don't
do that right now because the authentication agent currently doesn't run
in a separate security context.

Also, since some actions specifically ask for the admin password and
it's not a given that the user really is the admin. So no/yes won't work
either. We could do no/yes in case the user really is the admin though.

Once we port the authentication agents to run in separate security
contexts (e.g. different X server, all that jazz) we can look into this.

> So please port the trusted applications feature to polkit-1 and
> introduce these great security contexts using SELinux.

First, this conclusion does not follow since it as based on assumptions
refuted above. Second, exactly how many distros (other than Red Hat
based ones) run SELinux? Right.

     David