Malware protection?

[memolus at googlemail.com]

2009/11/30 David Zeuthen <david at fubar.dk>:
> Hi,
Hello David Zeuthen,

> I've been on vacation so that's why I'm only replying now.
I'm very happy enough about the fact that you answer at all. I'm very
interested in all the security details.

First question:
If you use non-one-shot authorization, the authorization is already
gone to the malware? Do you need any extra security hole?

> 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".
What about this:
> 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.
Does the magic daemon in another security context protect the
authentication dialog?

>> 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.
OK and what about short-time authorizations?

>> 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.
You didn't get my question. I wonder why you only need a separate
security context for an authorized application and no seperate
session. Because of your answer I conclude that malware can easily
hijack the authorized application, even if it runs in another security
context, because it doesn't run in another session.

>> 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.
If the malware could click yes and no, it could read your entered
password, too? I suppose the keyboard input is already exclusive
available for the authentication dialog, but you didn't found a way to
make the mouse input exclusive available for the authentication
dialog. Is it possible to hijack the authentication dialog if it
doesn't run in another 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.
For sure. If an user isn't already authenticated, you need to
authenticate him first.

> 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.
Great, but I wonder why policykit is possible without separate
security contexts at all.

>> 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.
No, it's not based on these assumptions. It's based on assumptions you
didn't refute.

Assumption: Malware should only have minimal authorizations.
→ You have to distinguish between malware and trusted applications.

You could to this by always asking for permission. You also could to
this based on a list of trusted applications and their trusted
actions.
Refutation, please.

> Second, exactly how many distros (other than Red Hat
> based ones) run SELinux? Right.
That's no reason. You could use it as an optional dependency. If it's
required, distros will ship SELinux, too.