Quelles sont les différences de sécurité entre le package click et .deb?

L'installation d'un .deb aléatoire (méchant?) Peut être dangereuse car elle accordera tous les privilèges aux applications et au démon installés car le .deb a des configurations demandant à appliquer si l'utilisateur valide son mot de passe lors du processus d'installation.

Cliquez sur le package n'a pas besoin d'un mot de passe (pour autant que j'ai testé).

Le package de clic sera-t-il plus sûr pour le système / les données utilisateur ou sera-t-il le même? Pourquoi?

Quelques aspects auxquels il serait bon de répondre:

• les clics et les deb sont-ils basés sur le même système (dpkg)?
• apparmor peut-il fournir un accès root aux applications sans mot de passe ou autre?
• l'utilisateur sera-t-il invité à accepter les droits d'accès des applications lors de l'installation (exemple de type android: ces applications seront en mesure de scanner votre / home et accéder au réseau) ou sur la course au besoin d'un droit (exemple de type navigateur demandant le droit d'utiliser la came) ?
• près de cette question: est-ce que .apk et click vont dire la même chose (à propos des politiques et de la user story) ?
• principalement: une application peut-elle envoyer toutes mes données privées sur le réseau en un clic sans me le faire savoir explicitement ou aura-t-elle au moins le droit validé par les utilisateurs pour le faire ou sera-t-elle de toute façon bloquée dans un bac à sable?
• Il est vrai de dire que les packages de clics sont moins puissants (restreignent plus de choses), mais plus sûrs?

Remarque: Je travaille dans l'équipe de sécurité d'Ubuntu et j'ai aidé à concevoir l'histoire du confinement des applications pour Ubuntu. J'ai reformulé les questions pour plus de clarté.

Q: "Les packages de clic seront-ils plus sûrs en ce qui concerne le système et les données utilisateur ou seront-ils les mêmes?"

R: En général, les packages de clics sont plus sûrs que debs en ce qui concerne les données système et utilisateur.

Les packages de clic n'incluent pas les scripts de maintenance qui s'exécutent en tant que root lors de l'installation comme les packages deb. Les packages de clic sont simplement déballés, puis les crochets fournis par le système sont utilisés s'ils sont déclarés par le clic. Par exemple, le clic peut déclarer l'utilisation d'un hook de bureau pour générer un fichier de bureau ou un hook AppArmor pour générer un profil AppArmor pour l'application. Parce que deb packaging a le concept de scripts de maintenance qui sont conçus pour permettre une personnalisation étendue du logiciel ou du système, les paquets deb ne doivent être installés qu'à partir d'une source fiable, par exemple une archive signée d'une distribution comme Ubuntu. Les packages Click peuvent être installés directement et vous pouvez être raisonnablement sûr que l'installation des packages ne ruinera pas votre système. Cependant, ce n'est qu'une partie de l'histoire - si vous installez un package de clic à partir d'une source non fiable,

Le véritable pouvoir du clic est lorsqu'il est utilisé en combinaison avec un référentiel de logiciels avec des politiques solides. Par exemple, la sécurité d'un package de clic installé à partir de l'App Store d'Ubuntu est généralement supérieure à celle d'un deb installé à partir d'une archive approuvée. En effet, dans l'App Store d'Ubuntu, le modèle de confiance est que les applications sont considérées comme non fiables * et que des politiques et des contrôles sont en place pour garantir que les packages de clics dans le magasin ont un manifeste de sécurité approprié et s'exécutent donc sous un confinement très strict. Contrairement à deb packages dans l'archive Ubuntu - le modèle de confiance est que le logiciel et le package deb sont considérés comme fiables et en général le logiciel ne fonctionne pas sous confinement (bien qu'il existe de nombreuses exceptions lorsqu'un profil AppArmor est livré avec le logiciel pour se prémunir contre les bogues de sécurité).

• Les paquets approuvés peuvent également être livrés via l'App Store d'Ubuntu. Bien que rares, ils sont généralement développés par Canonical et peuvent ou non fonctionner sous confinement.

Pour répondre à vos questions spécifiques:

Q: Le clic est-il basé sur le même système que deb?

R: Le format de package de bas niveau pour le clic est deb. Cependant, l'empaquetage de clics est beaucoup plus simple en ce qu'il utilise un manifeste déclaratif et des hooks plutôt que des fichiers d'empaquetage traditionnels et des scripts de maintenance.

Q: AppArmor peut-il fournir un accès privilégié aux applications sans interaction de l'utilisateur?

R: AppArmor possède une racine solide et peut autoriser ou refuser l'accès aux ressources système (fichiers, DBus, réseau, etc.) en fonction de la politique de sécurité définie. Un package de clics seul n'est pas requis pour expédier un manifeste de sécurité AppArmor ou pour expédier un manifeste de sécurité AppArmor qui est «sûr». Ce qui sécurise le système, c'est la combinaison du clic et des politiques du magasin qui fournit les packages de clic. Les packages de clics fournis via l'App Store d'Ubuntu utiliseront la politique AppArmor qui est très restrictive et ne permet pas d'actions privilégiées en arrière-plan (par exemple, une application exécutée sous cette politique ne peut pas exécuter de programmes sur le système en arrière-plan, accédez à votre compte Facebook , volez vos clés gpg ou ssh, manipulez le réseau, etc.)

Q: L'utilisateur sera-t-il invité au moment de l'installation à accorder des droits d'accès à l'application comme sur Android? (par exemple, "cette application peut analyser votre / home et accéder au réseau")

R: Non. Un package de clic lui-même peut être installé sans invite à l'aide d'outils de bas niveau. Sur Ubuntu, les packages de clic doivent être installés via la boutique d'applications Ubuntu (voir ci-dessus) et en raison des politiques de la boutique d'applications Ubuntu combinées aux capacités de clic et au système Ubuntu, il n'est pas nécessaire de cliquer sur des invites d'installation sans contexte. Ubuntu peut le faire parce que les applications installées à partir de la boutique d'applications Ubuntu fonctionnent sous confinement restrictif (c'est-à-dire qu'elles ne peuvent pas faire de mauvaises choses en arrière-plan) et lorsqu'une application a besoin d'un accès supplémentaire, elle le fait en utilisant des API contrôlées qui peuvent inclure des invites.

Dans le cas des API privilégiées, nous avons le concept des assistants de confiance tels que l'utilisateur aura une invite contextuelle pour autoriser ou refuser l'accès (avec une mise en cache révocable (facultative) afin que l'utilisateur ne soit pas invité à chaque fois). Par exemple, si l'application doit accéder au service de localisation (un assistant de confiance), l'utilisateur sera invité à autoriser l'accès au moment où l'application essaie d'utiliser le service de localisation, ce qui donne un contexte afin que l'utilisateur puisse créer un décision éclairée. La même chose se produira pour l'enregistrement vidéo et audio. Souvent, nous n'avons pas du tout besoin d'avoir une invite de sécurité et nous pouvons autoriser l'accès en fonction des interactions utilisateur avec l'application. Par exemple, si une application souhaite télécharger une image, il y aura une boîte de dialogue pour sélectionner l'image. Dans les coulisses, car l'application n'est pas autorisée à accéder au répertoire ~ / Pictures, il utilisera l'API content-hub qui lancera le sélecteur de fichiers de galerie pour que l'utilisateur puisse choisir une image à télécharger. Le hub de contenu prend ensuite la photo de la galerie et la donne à l'application. De cette manière, il n'y a pas de dialogue de sécurité, il n'y a qu'une interaction naturelle pour l'utilisateur, mais en coulisse, il y a une décision de confiance implicite.

Q: En relation avec cette question: est-ce que .apk et click auront un langage similaire en ce qui concerne les politiques et les expériences utilisateur?

R: Non, il n'y a aucune invite d'installation pour les raisons indiquées ci-dessus. Les autorisations Android et les autorisations de sécurité pour les packages de clics définis pour Ubuntu présentent certaines similitudes, mais sont différentes et implémentées différemment.

Q: Plus précisément, avec un clic, une application peut-elle envoyer toutes mes données privées sur le réseau sans que je le sache ou sera-t-elle confinée d'une manière ou d'une autre pour empêcher cela?

R: Si vous installez un clic à partir d'une source non fiable, oui, il peut tout faire. Si vous installez un clic à partir de l'App Store d'Ubuntu, non, une application ne peut pas envoyer toutes vos données sur le réseau car elle n'y a pas accès. Bien sûr, une application peut sembler faire une chose et faire une autre, donc si un utilisateur accorde l'accès au service de localisation ou donne à l'application l'accès à une image, l'application peut être mauvaise avec ces données - mais c'est là que les évaluations / avis et les politiques de sécurité de l'App Store entrent en vigueur. Si une application comme celle-ci est signalée, elle fera l'objet d'une enquête. Le cas échéant, l'application sera supprimée de la boutique, l'application sera supprimée de tous les appareils sur lesquels elle est installée et l'accès à l'App Store du développeur sera révoqué.

Q: Peut-on dire que les packages de clics sont plus sûrs que debs, mais moins puissants car ils sont plus restreints?

UNE:Comme on peut le voir ci-dessus, la réponse n'est pas aussi simple. Un simple clic peut expédier un logiciel qui peut tout faire. Le format d'empaquetage par clic est intentionnellement à usage général et peut être utilisé de différentes manières et n'est pas du tout spécifique à Ubuntu. Pour Ubuntu, la combinaison du clic, des API Ubuntu, d'AppArmor et des politiques de l'App Store fournit un environnement très puissant aux développeurs pour fournir des applications aux utilisateurs d'une manière sûre et facile à utiliser pour les utilisateurs. L'utilité des applications elles-mêmes dépend des API proposées aux applications par le système sous-jacent. L'ensemble initial d'API qui sera offert sur les premiers téléphones d'expédition d'Ubuntu permettra aux développeurs de créer toutes sortes d'applications amusantes et utiles à l'aide d'une API et d'un SDK riches.

J'essaierai de répondre à certaines des questions les plus importantes concernant la sécurité et les packages de clic.

• Une application peut-elle envoyer toutes mes données privées sur le réseau en un seul clic sans me le faire savoir explicitement?

  • Les applications Click seront exécutées sous confinement. Cela signifie que l'application est empêchée de faire de mauvaises choses: elle ne peut accéder qu'à son propre répertoire privé.

• Les applications peuvent-elles être installées et avoir ensuite des droits root? sans mot de passe ou invite spécifique?

  • ...

• L'utilisateur sera-t-il invité à accepter le droit des applications? quand?

  • Cliquez sur les applications pour accéder aux fonctionnalités que l'utilisateur autorise à utiliser l'application (NB: invite pas encore sur la version actuelle / quotidienne d'Ubuntu Touch) .

• Est-il basé sur le même système pour le clic et le deb?

  • L'emballage de Debian (.deb) est complètement différent. Cependant, si votre application est créée avec le SDK Ubuntu, vous n'avez pas besoin d'utiliser le package Debian et pouvez plutôt utiliser le package Click, qui est beaucoup plus facile à utiliser et beaucoup plus sûr pour l'utilisateur final.

• Similaire comme ci-dessus, pour comparer: Do .apk (Android) et click fonctionnent-ils de la même manière?

  • Les packages Android et les packages Ubuntu Click fonctionneront de la même manière, en ce sens que chaque application aura son propre espace pour stocker les données et qu'il est (idéalement) interdit d'accéder directement aux données d'autres applications. Actuellement, les packages Android peuvent également lire les données de la carte SD ou du stockage interne, où il n'y a aucune restriction d'accès. Les packages Ubuntu Click devront également demander des autorisations pour des fonctionnalités spécifiques.

• Il est vrai de dire que les packages de clics sont moins puissants (restreignent plus de choses), mais plus sûrs?

  • ...

Pour ces raisons, les packages Click sont très sûrs et le processus de révision pour les publier est beaucoup plus simple.

Sources:

• /ubuntu//a/345217/85273