Malware protection?

[memolus at googlemail.com]

>Also I'm not exactly sure what you mean by 'malware protection'
Malware protection means that the user and not the malware decides, so
that an policykit action is not available to malware, only to trusted
applications, where the user decides and which can't be controlled by
malware. It means:
* Only trusted applications are allowed
* Trusted applications are in another security context,
  so that they can't be controlled by malware
* Malware isn't able to steel the password

>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?
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. Also I wonder, why you need an separate
session for the authentication agent, but only a separate security
context for an authorized application.

>(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.)
For sure it's for non-consumer setups more important to protect root
access, because they have a lot of users on the same computer. But if
you remove the secure attention key, any malware could spoof the
dialog. So you wouldn't have malware protection for consumers anymore.
They need malware protection, too, but of course in a more
userfriendly way.

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.
I don't get why one-time authorization is saver. Isn't it just a
smaller time frame? You could use another security context for always
authorized applications, too.

At all you only need this "yes/no dialog" only the first time. If the
application is already marked as trusted, you would be able to use it
whenever you want without the need for any additional authentication.
Malware wouldn't be able to controll your application, because it's in
another security context.

So please port the trusted applications feature to polkit-1 and
introduce these great security contexts using SELinux. There should be
a way to verify that an trusted application is started in another
security context.

Create an new directory called "/usr/share/polkit-1/applications".
There you have files called e.g. "update-manager.app" with the
following style:
[Update Manager]
Path=/usr/bin/update-manager
Actions=org.freedesktop.packagekit.system-update,org.freedesktop.packagekit.package-eula-accept

(You could also allow any programmm in /usr/bin, but maybe someone has
installed malware in /usr/bin, who knows?)

Additionally have have such a directory in each home directory
(~./config/polkit-1/applications) which is owned by polkituser, so the
user itself has no rights on it. This is useful for user-specific
software. If an nontrused application asks for authorization, you are
asked if you trust this application. If you choose yes, the
application is added to "~./config/polkit-1/applications".

Then you add the "keep authorization always" feature again. If you
choose "keep authorization always" an new authorization is added to
the user. You could use .pkla files, but I think a file per user would
be better for this purpose and better for a GUI permission manager.
E.g

[Permissions]
Identity=unix-user:bob

[org.freedesktop.packagekit.system-update]
Authorized=yes
ResultAny=no
ResultInactive=no
ResultActive=yes

[org.freedesktop.packagekit.package-eula-accept]
..

I propose to remove "Auth" and "Ask_Admin". In the shown file "No"
means "No", if the admin doesn't want to be asked, and "Ask_Admin", if
the admin enabled "Ask_Admin". Note that an admin has all
authorizations.
If you got an authorization from your admin (Authorized=Yes), you can
add or remove your authorization for certain sessions (Any, Inactive
or Active) yourself. If you remove your rights for "Any" and then want
it back during a remote session, you have to change this setting in a
local session or use "Ask_Admin" from remote session.

If an application asks for an authorization:

if (trusted_application == false) { through new NotTrustedAppError(); }
if (application_is_in_another_security_context == false) { through new
SCError(); }
if (action_or_pkla_authorization == true) {
  return;
}
if (user_is_authorized == true) { return; }
} else { trough new UserNotAuthorizedError(); }