Malware protection?

[David Zeuthen]

Hi,

FWIW, as I've said a couple of times, the long term plan is to have the
authentication agent run in a session _separate_ from the login session.
Think fast-user-switching. The reason we are not doing this yet is that
it depends on some work in the graphics stack being done.

When we do this, even malware cannot snoop your password... provided we
force the poor user to use the SAK (secure attention key, e.g. Ctrl+Alt
+Del) to get to the session with the authentication dialog.

(Of course, no-one in their right mind wants to do this on a consumer
desktop OS. But it might be useful in non-consumer setups.)

Also I'm not exactly sure what you mean by 'malware protection' - by the
very definition of "security context" you cannot protect against this
unless you have multiple security contexts in your session (e.g.
sandboxes, SELinux). And this doesn't seem to happen a lot neither on
Windows, Linux or any other big OS. The closest we have is something
like Google Chrome where the renderer process (which processes untrusted
content) is sandboxed.

(I'm using the term "security context" in a loose way here - basically I
use the term to mean that it's not possible for a process in a given SC
to inject code into a process in another SC.)

Also, temporary (non-one-shot) authorizations (the ones you gain by
authenticating) are indeed limited to the process it is for. But of
course anyone can inject code into such processes if they run in the
same security context. So non-one-shot authorizations (aka temporary
authorizations - the ones that cause a lock icon to appear in the
notification area) are not very good to use for situations where it is
easy to gain root. They are _useful_ for other things though - such as
messing around with disks and configuring other parts of the OS.

However, one-shot authorizations are safe _provided_ the authentication
agent lives in a separate security context than your possibly
compromised session and that the mechanism used runs in another security
context.

For example, 'pkexec bash' is indeed safe even when your session is
compromised exactly because (one-shot) authentication would happen in
another security context (and because pkexec(1) itself runs in a
separate security context because it is setuid root). 

(Which is a lot better than both su(8) and sudo(8) since they rely on
the (possibly compromised) session to authenticate you.)

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.

Hope this clarifies.

(I'm actually glad you are asking tough questions like this - I'm
planning to extend the docs with a lot of background info like this.)

     David