Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

SXE - Application Level Policy

Service Access Control

In general programs may access services, which in the context of the SXE, can mean low level graphical display services provided by QWS to high level Application Services. Service access is achieved by sending IPC calls to the Qt Extended system, for example via QCop messages. Application level policy refers to policy which dictates what services a program may and may not access.

In the current implementation of Qt Embedded the IPC calls are in the form of streamed data sent through a Unix Domain Socket (UDS). Currently the entire graphics subsystem is implemented via a system of QWSCommands over this socket, combined with reads/writes to a piece of shared memory.

Because a program requires access to the well known path to the Unix Domain Socket for the QCop system in order to send low-level requests to the Qt Extended windowing system, it is not practical to use MAC file system rules to control access to services.

Control of access to services involves two important steps:

  1. authentication : identify profile of the program which sent the request
  2. authorization : check the policy rule for that profile and request

Now the terms program and request require definition.

A downloaded application package may be thought of as containing one program such as a game, or an image manager.

That application may however be made up of a number of binaries, and other files. In some cases a single binary may make up the totality of the package but sometimes the picture is more complex than that.

For example, a game may have a level editor, the main game binary, and a daemon process. While the game itself and the level editor may also be thought of separate applications, both are considered to be part of the same program.

The SXE system applies policy rules to each program component by associating a progId with all the components of that application. The progId has a one to one relationship with the domain the application operates under, therefore all untrusted applications have the same progId while all trusted applications have another.

When a program wants to access functionality available via Qt Extended in general it must use the QWSCommand system, or send a QCop message or otherwise ask for an application service. Generally these accesses can be expressed as a string for example in the case of a QCop message requesting a wait indicator to be displayed: QPE/System/notBusy()

Such an access for a service, and the string representing it, is referred to as a request.

Request Authentication and Authorization Procedure

The procedure for authentication and authorization is presented in the following steps:

  1. Process an incoming message:
    • Verify that the message is a valid message
    • If the transport is untrusted, confirming validity requires a Message Authentication Code.
    • Check if authentication information is included
    • Un-marshall the message and prepare to process the request
    • if the request is in an allow whitelist, procedure complete, process request
  2. Determine the progId and hence profile of the program that is sending an incoming message:
    • if the message transport is trusted either a simple shared secret or Unix domain socket ancillary data identification will suffice.
    • if the message transport is connection oriented the program identity may be cached against the file descriptor or other identifier for the connection.
    • the program identity need only be extracted from authentication information included in the message once validity is confirmed
    • if the shared secret is incorrect then
      • deny any requests not in the allow list.
      • if a threshold of 5 or more failed authentications in minute occurs, log a security breach to lockdown all downloaded applications. See SxeMonitor
  3. Check the policy for the request using the progId:
    • look up the security profile/domain awarded to that progId in sxe.policy.
    • look up the list of requests allowed for that profile in sxe.profiles.
    • if the request is in one of the profiles the message is processed normally.
    • if the request is not in one of those profiles:
      • deny the request
      • log the security breach so that SxeMonitor can respond

Program Identification

In the authorization procedure described above it states that the authentication may be done simply if the message transport is trusted.

If the message transport is trusted four assumptions must be fulfilled. The table below lists these assumptions and how, or if, they hold in the Qt Extended Base module.

AssumptionComments
The transport cannot be intercepted for example, as in a man-in-the-middle attack or traffic-sniffing scenario.Unix domain socket traffic cannot be sniffed or rewritten on a standard Linux kernel. However, the following can be sniffed/intercepted:
  • files
  • UDP
  • shared memory
  • message queues.
The transport end-points cannot be spoofed or subjected to a symlink attack.
  • Unix domain socket end-points can be subjected to symlink attack and process identity can be spoofed; but both of these can be prevented using specifically crafted MAC kernel rules.
  • Files are subject to symlink attacks, and IP endpoints can be spoofed, though TCP will break down since the syn/ack will not work.
  • The kernel will ensure the identifier key for message queues
The transport is reliable and well-behaved as determined by the platforms kernel and/or network stack
  • UDP is not reliable, other transports generally are.
  • Kernels should be audited and supplied by trusted partners.
The client program cannot be compromised for example by an LD_PRELOAD attack or by directly accessing the binary image file on disk
  • MAC rules can prevent accesses to the binaries.
  • If access is prevented the LD_PRELOAD attack is not a problem but there may be some cases where a binary needs to be launched by an untrusted program. This seems unlikely but if so, the MAC kernel can be specifically configured to clean the environment passed to execve

Note: Current QCop messaging (which is used for almost all service requests in Qt Extended) uses Unix Domain Sockets.

Summarizing the above table

If the assumptions hold - the kernel and MAC controls can be relied upon to prevent a range of security risks - a simple password-based mechanism can be used at connection setup time to authenticate the connection, or Unix Domain Socket ancillary data can be used.

The second option is more complex than the password method, and carries a portability warning. However if the Unix Domain Sockets rights methods are required for passing file handles that method can be used.

In several scenarios where one or two of these assumptions are not valid the password based mechanism can be simply expanded to HMAC-MD5 message authentication.
Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 64
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. BlackBerry 10 : premières images du prochain OS de RIM qui devrait intégrer des widgets et des tuiles inspirées de Windows Phone 0
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. La rubrique Qt a besoin de vous ! 1
Page suivante

Le Qt Developer Network au hasard

Logo

Comment fermer une application

Le Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt qtextended4.4
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum Qt

Blogs

Hébergement

 
Partenaires

Hébergement Web