The goal here is to ensure that Ubuntu users can make an informed choice about what applications they want to install. This informed choice should not only be based upon the features of the application but also how support the application is.

There are two types of application that the Ubuntu Software Center will show:

1. Officially supported apps - these are the apps in main that are supported as part of our support policy. These are likely to be older version but releases with assured integration and security fix support.

2. Developer uploaded apps - these are the apps that app devs can upload. These are not supported by Ubuntu developers and the app developer is responsible for any quality and integration considerations.

We would need some design input on the best way of presenting this information.

Implementation

App Preparation

This step deals with how app authors will prepare their app before submitting it to MyApps and starting the app developer upload process. We want to be able to help and support our app developers to submit their applications in a format that can be easily processed for inclusion in the Ubuntu Software Center.

MyApps will accept one of the following formats (please note the priorities listed that indicate the order in which we want to build this support):

We will continue requiring applications to be installed to /opt/, but will make this transparent to the developer by fully supporting relocatable packages in all of our build tools and runtime systems. Once relocation is supported, the developer will not need to make any changes to their source code or source package in order to target /opt/, they will only need to build the binary by passing a special flag to debuild. When their package is built by MyApps, the same flag will be used to ensure that the resulting binary will be properly installed into /opt/.

When needed for desktop integration, a set of whitelisted locations within /opt/ has been defined where applications will be able to install files. The same or equivalent set of tools will be run on the server side to do the checks.

The whitelist of approved installation locations is:

On the client side, Quickly and pkgme will integrate a custom Lintian profile to do the checks for whitelisted location (and any additional ones required) and will output warnings or errors to indicate whether the local app might need to be fixed before being submitted.

While this specification is concerned with apps created by the tools that Ubuntu provides (which in this case they are Quickly), app developers that write their apps outside Quickly should be able to get their software prepared in the same form Quickly does.

A further step towards better process automation would be to provide an API to enable Quickly to directly send the application to MyApps. While this would streamline the process, it is considered non-essential for the current revision of the spec.

Security Profile Testing

In order to iteratively test their application under an AppArmor security profile, developers will be provided with a tool that will generate and install a working profile built from a simple config file. This tool will be available as a stand-alone commandline program, as well as being integrated into Quickly. It will facilitate the creation and installation of a local AppArmor profile, as well as running the application under this profile to test it's functionality inside of the sandbox.

The tool will read a list of requested abstractions from a simple text file (INI, or other format), and apply those on top of the Ubuntu Application profile template using aa_easyprof. Developers using Quickly should be able to add and remove abstractions from this file using Quickly commands. Developers not using Quickly would still be able to edit the file by hand. The config file should be included as part of the source package submission so that it can be used by MyApps to pre-populate the security profile form for the developer.

Namespace conflict checking

Applications installed in a system may come from diffferent sources, that is, from different archives: mainly Main (including backports) and Extras (where apps concerned with this spec reside).

There is currently no infrastructure in place to provide a connection between the archives in terms of checking that their packages or the contents of those packages don't clash. This does not only apply to independent archives, but also to repositories within a self-contained archive. Also worth noticing is that this is not an issue introduced by this spec, but an already existing one.

In summary, there is a small but real possibility for packaged applications submitted through the app developer process to essentially (a) install files in the same location as another package coming from the Main archive or (b) to use a package name already in use in the Main archive.

Both cases would create a file or package conflict situation which the packaging tools would not be able to fix. Note that the potential scope for (a) would only affect the whitelisted set of installation locations for third party apps. Case (b) is further addressed in the Package preparation section by prepending the extras_ prefix to Extras packages to avoid collisions.

Conflict checker

A solution to this problem would be to use an automated conflict checker service. The idea is that the contents of all archives are read into a database and then a comparison is made upon any submission to MyApps. MyApps would query the conflict checker and would inform the submitter of any file conflicts that need to be fixed before upload.

The idea is that the conflict checker has data about all archives, but only runs for Extras before each upload: to inform the uploader about conflicts and prevent uploads until they have been resolved. If this proves to be a useful feature, it could theoretically be extended to all of the archives in a future iteration, so that not only Extras apps would benefit from conflict checking, but also all software in the Main archive.

For each new distro series, Extras will be open at Beta time. Just before opening the archive, the conflict checker will also be enabled for that release and will continue running for the lifecycle of the distro series. For newly submitted applications, conflicts will be detected and Extras uploads will be blocked until the conflicts have been resolved. For existing Extras applications which may present a conflict with a Main application, the Main application will take precedence in terms of file namespace ownership (as outlined below). In this case, an e-mail notification will be sent to the app developer to fix the conflict and reupload their app, and the Extras package will be marked with a Conflicts: field against the Main package. If the app developer does not act upon it, their app will be uninstalled when users do the upload to the stable release.

The conflict checker should be aware of and able to handle:

• Alternatives

• Diversions

• Conflicts/Replaces

• Conflicts within the same archive

In terms namespace ownership, the proposal is to use the following priorities:

1. Main
2. Extras
3. Backports

That means the archives that are higher on the list get to own the namespace when there is a conflict with an archive with a lower priority, and the uploaders on the lower priority archive need to resolve the conflict.

The current conflict checker (currently not in use) and the packages.ubuntu.com site are two examples of existing infrastructure using a similar approach.

Potential cases

• John uploads "Wikitron" (/usr/bin/wikitron) to Extras via MyApps. Afterwards, Jane uploads "DesktopWiki" (also /usr/bin/wikitron) to Backports

  • Solution: conflict checker warns Jane about the conflict via an e-mail. She must fix the conflict before a new upload is accepted.

• George uploads "Lightread" (/usr/bin/lightread) to Extras through MyApps. An existing package called "LightReader" (/usr/bin/lightread) exists in the main archive already

  • Solution: conflict checker warns George about the conflict via an e-mail and on the MyApps web UI. He must fix the conflict before a new upload is accepted.

• Herbert uploads "bird-game" (/usr/bin/bird-game) to Extras via MyApps. An existing package called "animal-games" (with /usr/games/bird-game) exists in the main archive already. Calls to "bird-game" will match the one in /usr/bin/ before the one in /usr/games/

  • Solution: extend conflict checking to match any file under a directory in $PATH to any other file in a directory under $PATH. Possibly need to do the same for libraries.

• Oswald uploads package "notes" to Extras via MyApps. Afterwards, Persephone uploads an unrelated package, also called "notes" to Debian. During the Ubuntu+1 package sync, Persephone's "notes" package will be pulled into Universe.

  • Solution: Prefix Extras packages with extras_ to avoid package name conflicts

    • If the package gets moved into Debian or Ubuntu's archives, we would need to transition the users who have the extras_ package installed over to the non-prefixed package.

Developer Request

Applying for access

To ensure that we are giving upload access only to the original author or a proper representative of the upstream project, we will require that person to request upload access for their application. The author or representative must first create an account and user profile in the MyApps portal as it currently exists.

Once their profile is created, they will need to be able to request upload access for a package, providing details about their association with the upstream project. If the submitter is not the owner or representative of the project, they will be required to provide a URL to a webpage, blog post or mailing list archive showing that the owner or representative of the project is endorsing their effort upload the application to the Ubuntu Software Center.

A link will be presented on their user profile page that will point to a new page containing a form for the developer to fill out. The details required by the form should be sufficient for a review board to determine whether or not the requesting user meets the requirements to represent that project. The review board will be responsible for developing the detail requirements, but it should include the following:

1. The developer's first and last name (e.g. Joe Smith).

2. A contact email for the developer (e.g. joe.smith AT email DOT com)

3. The name of the package(s) that the user wishes to upload (e.g. accomplishments-viewer). This could be more than one package if required.

4. If the developer is the sole owner of the application, they need to tick a box to verify that they are copyright owner, representative, or endorsed package provider for the project. This would be in the form of a textbox in which the user prepares a summary of their involvement in the upstream project with content such as the following recognized:
   • Project information page listing the user as the creator or current owner of the project
   • Links to commit logs from the user.
   • Active participation in the project strategy and discussion (such as mailing list posts).
   • Testimonials from other members of the project.
   • Links to an specific endorsement for uploading the application to the Ubuntu Software Center

In addition, the form should include an agreement text stating that the requesting user assumes responsibility for the maintenance and content of the package they are requesting access to upload. This information will be saved to the MyApps database. More than one of these requests may be made by the same MyApps user, if they wish to maintain more than one package in the Extras archive.

Developer Verification

There will be two methods to get verified and thus be able to submit apps to MyApps:

Given the number of developers who are expected to to start using this new upload process, it is likely that there will be times when, for one reason or another, we will need to revoke their access. This will occur when the terms of conditions of the service have been breached. Some potential causes for access revocation include, but are not limited to:

1. Attempting to upload malicious content.

2. Uploading content in violation of the Extension Repository Policy

3. Uploading content in violation of copyright, trademark, or other legal restrictions.
4. The owner or representative of a project objects to their upload access.

Revoking access is something that will only occur in situations in which the terms and conditions have been breached. Access will be revoked by changing the status of the user's upload request record from "Approved" to "Revoked" in MyApps.

Access will not be revoked if an application is considered poor quality. The ratings and reviews system is a useful approach in which our users can communicate their dissatisfaction (or satisfaction) with an application and help other users to make a judgement call of whether to install it or not.

In the case of content in violation of the Extras archive policies, users can submit an abuse complaint that will be reviewed by the review board indicating the application and what content they feel is objectionable. The review board will then contact the developer to determine whether the application can be resolved so that it complies with the archive policies. If it can not, the review board will meet to determine whether the application should be removed from the archive and the developer's upload access for that application will be revoked.

In the case of a legal violation, such as copyright or trademark, either the review board or Canonical will receive the complaint from the copyright or trademark holder. In this case the review board will immediately remove the package from the archive and suspend the developer's upload access until the issue has been resolved. They will then contact the developer with information about the complaint, and determine whether the application can be fixed so that it is no longer in violation. If it can not, the review board will permanently revoke the developer's upload access for that application.

The Ubuntu Software Center, when viewing a package from the Extras archive, will display an additional link for reporting abuse by the package. The link will direct the reporter to a page on MyApps with a form for detailing the abuse being reported, and optional contact information about the reporter. The form should include a radio option listing the 4 reasons for revoking access listed above, or an optional "other" reason that the reporter must specify.

Revokation will be done by the review board through the identification page outlined in the section above.

Security Policy Preparation

Once an application is installed, AppArmor will provide a security sandbox to protect the user from malicious or simply broken code. To accomplish this, each application will need a properly constructed, and minimally permissive profile to restrict what the application can access on the local system. Producing such a profile, and more importantly checking it for correctness, is currently a very manual process.

AppArmor Creation

In order to reduce the complexity of the AppArmor profiles used by applications submitted to Extras, the author is asked to fill out a form describing the access needs of their application. The options presented will correspond to the following pre-defined Policy Groups used by the AppArmor Easy Profile (aa-easyprof) script.

Default Permissions

Permissions are handled by using templates and then declaring additional permissions in the form of policy groups. For 13.10 the templates are:

• ubuntu-sdk (default)

• ubuntu-webapp

• unconfined (reserved)

Note: application confinement for Unity scopes will not be supported in 13.10.

The following AppArmor policy abstractions will be given by default (ie, when using the 'ubuntu-sdk' template:

Any additional permissions chosen (other than those under Default above) are declared by the developer in the form of policy groups.

The author may also choose from various policy groups. In 13.10 the common set (ie, those available to all applications) consists of:

• accounts - Can use Online Accounts
• audio - Can play audio
• camera - Can access the camera(s)
• connectivity - Can access coarse network connectivity information
• content_exchange - Can request/import data from other applications
• content_exchange_source - Can provide/export data to other applications
• location - Can access Location
• microphone - Can access the microphone
• networking - Can access the network
• sensors - Can access the sensors
• video - Can play video

A reserved set of policy groups is also provided for apps that need special confinement-- typically Canonical-supported apps like the gallery, media player and music player. Eg:

• picture_files - Can read and write to picture files. This policy group is
• picture_files_read - Can read all picture files. This policy group is reserved
• music_files - Can read and write to music files. This policy group is
• music_files_read - Can read all music files. This policy group is reserved
• video_files - Can read and write to video files. This policy group is
• video_files_read - Can read all video files. This policy group is reserved

It is also possible for apps to declare the use of additional abstractions, read paths and write paths. Developers are discouraged from using this as it will redflag the application for manual review which will slow down the review process significantly. App developers should either find another way to work within the existing permission set, or file a bug to see if it can be added to the policy.

AppArmor Integration

Because the security and stability of the user's system will depend more on the inability of running applications to cause problems than on a manual review of the application identifying them, a robust sandbox will be needed to prevent any un-granted access.

AppArmor is the preferred way of providing mandatory access controls (MAC) on Ubuntu, and it will also serve as the basis for most of the application sandboxing that will be applied to the application. AppArmor will provide the following necessary restrictions:

• Limit filesystem read and write access to a pre-defined whitelist of files and directories
• Restrict an application's ability to access the network
• Limit what network destinations an application can request
• Limit what DBus service the application can call
• Prevent an application from listening in on other applications' DBus communication
• Limit what external programs an application is able to call
• Limit what signals an application is able to use and where to send them
• Force any external programs to run under the same restrictions as the calling application

• Display manager/server (requires kernel and userspace support from AppArmor as well as support from the display manager/server)

  • Prevent an application from listening in on another application's keyboard/mouse input and output
  • Restrict an application's ability to perform screenshots outside of its window
  • Restrict an application's ability to access the clipboard
  • Restrict an application's ability to perform drag and drop
  • Limit/Support 3D in some manner

In addition to AppArmor, sandboxing will be required by these other parts of Ubuntu as well (list subject to change):

• DConf/GSettings
  • Prevent an application from writing to system-wide or session-wide settings
  • Prevent an application from reading or writing to another application's settings
  • Prevent Gtk from loading and executing additional modules based on an application's settings
• GNOME Keyring
  • Prevent unauthorized applications from obtaining credentials
• Ubuntu Online Accounts
  • Prevent unauthorized applications from obtaining credentials
• Location service

On the converged device, it is expected that toolkits may need to be patched to gracefully handle sandbox denials. Eg, prior art showed that some applications will crash when faced with an X denials so we'll need to be careful about any sort of display manager/server denials in our toolkits.

Some parts of the environment will need to be adjusted for confined applications to work correctly within a confined environment (eg, setting XDG_* base directories to default values, TMPDIR or other environment variables). The SDK and application launchers will make this transparent to the developer.

Helpers

Because application authors will only be able to choose from a predefined set of access policies, some services may use a proxy service that will allow the application to extend its access beyond the confines if its AppArmor profile with the user's approval. This service will broker requests for additional access between the application and the user, and either dynamically expand the application's sandbox, put a copy of the content into the application's sandbox, or allow the application to read and write through the proxy service itself.

When the application needs to open a file outside of its sandbox, it will call the content-hub service running outside of the sandbox. The content-hub service will then prompt the user to select the file(s) using a file chooser, gallery app, etc. Only after the user makes and approves of the selection will the application be given the ability to access it.

Helper services may in the future provide content guarantees by checking and/or converting the format of what is being saved. This would allow the user to approve writing files of a certain type, such as an png image, to a location outside of the AppArmor sandbox. When the application attempts to save data to this location, the service will verify that the content matches what has been approved, and either convert it (if possible) or reject it.

If a request is made to the helper service for a file or resources that the application already has access to, it should return that resource immediately, without needing additional approval from the user, so that the developer doesn't need to use separate APIs for accessing files inside and outside of their application's sandbox. In order to encourage the use of calls to these helper services, our documentation and tutorials should recommend the use of these APIs for all file access needs, and they should be included in and used by the Quickly templates we provide.

App Review

As part of this process, the successful applicants will be given upload rights to their software. This will enable them to upload their packages without any further review, given that they conform to the rules set out in the App Preparation section. In addition to those rules, MyApps will perform a series of automated checks against the submitted source package to further ensure the safety and stability to a user's system.

If an app does not pass the automated checks in MyApps, it will remain in Draft status and the app author won't be able to submit it until any warnings or errors have been addressed. This will require tools like Lintian to be run on the submitted source package, which is a process that can take in the order of minutes to be finished. Thus there should be a mechanism to asynchronously show any status messages in the MyApps UI and to send a notification e-mail to the uploader. The checks can either be triggered when pressing the 'Submit' button at the end of the process, or already when the source package is uploaded.

Package preparation

MyApps will unpack the submitted Debian source package to make a small number of changes to it.

First it will add the generated AppArmor profile to the source package. By integrating the profile in MyApps, rather than having the developer do it, we both relieve the developer of an extra step, and assure ourselves and our users that the profile is properly setup.

Then it will prefix the package name with extras_ to prevent namespace conflicts. Once again, doing this on MyApps relieves the developer of an additional step that they won't necessarily care about, and helps us avoid potential name conflicts with new packages that may come in to Ubuntu or from Debian.

Finally it will rebuild the source package, signing it with the MyApps GPG key. The source package will then be uploaded to the staging PPA to be built into a binary package. A link to the resulting binary package will then be displayed on the submission page in MyApps, which the developer can use to install and test their application running sandboxed under the newly created AppArmor profile.

DBus Service Restrictions

If a submitted application will be installing a DBus session bus service, a further check will be performed to prevent service name conflicts. To accomplish this, a complete list of service names must be maintained and used to verify any new service names.

To create the list of all service names, a one time scan of the archives will be performed at the point in each development cycle where the Extras archive is opened for the new release. This scan will perform the following:

1. Find packages with a .service file

2. Download the package

3. Extract any .service files from the package

4. Parse the DBus service name from the .service file

5. Append both the source package name and service name to the list

Whenever a new package is submitted to MyApps, it will be scanned for the presence of a .service file. If one is found, it will be extracted from the package, have its DBus service name parsed and checked against the list. If no match is found, the new package and service name will be appended to the list, and the submission will be allowed to proceed. If a match is found, the submission will be rejected. MyApps will display this conflict on a review page for the developer, showing both the conflicting service name and any existing packages that are using it.

Packaging Restrictions

The Security Team raised the concern that packaging dependencies should also be checked to ensure they cannot introduce security regressions or vulnerabilities. These will only deal with dependencies and not other packaging fields or aspects. This should be an automated check that in practical terms will be coded in a Lintian profile to be run on the server and that will reject the submission if the checks raise a warning. MyApps will display this warning on a review page for the developer.

The current list of rules to check for in the new Lintian profile is:

• Only reject Depends relationships with = or <= in the Debian control fields of the package

• .desktop files should not specify an interpreter for the Exec (ie, 'Exec=/bin/sh foo', 'Exec=/usr/bin/python /opt/foo/bar'). In other words, what is in the Exec line in the .desktop file must match the binary specified n the AppArmor profile. A simple but likely good enough check is to ensure that the executable starts with /opt/<namespace> (eg Exec=/opt/foo/...)

Package Updates

Developers will be able to submit new versions of their application any time after their first publication. Whenever a new version of their package is submitted through MyApps, it will undergo all of the above automated tests and modifications as their first submission. If the new version of the application fails any of the above requirements, that version will be rejected and the previously accepted version will remain.

Upload

Once all the app itself, its metadata and security profile have been integrated into a source package, the server will initiate the process of uploading, building and publishing a distributable binary package.

pkgme will be the piece of infrastructure that will do most of the work at this this stage. The main goal is again automation and not having to rely on human intervetion for the upload step. Following this premise, the steps will be:

1. Pkgme uploads the final source package containing the AppArmor profile to the ARB PPA

2. The ARB PPA is synced automatically (hourly) to extras.ubuntu.com
3. The final binary package appears on extras.ubuntu.com and is distributable at that point

Extras Archive

The Extras archive is central to providing an improved process for uploading applications to the Ubuntu Software Center. This archive will combine the features of both the distro archives and Launchpad PPAs in a way that provides both developers and users with reliable access to the latest versions of applications.

Rules Changes

To reduce the time and effort required to get an application into the Extras archive, the need for manual review of an application's source code will be removed. Instead, a proper application sandbox and associated AppArmor profile will prevent both accidental and intentional abuse of a user's system. A manual review will not be needed to verify the security profile, because the profile will be generated by MyApps using a list of pre-approved policy options.

New Release Process

Ubuntu has a long history of being stable and secure, a reputation that was made possibly by careful and thorough reviews by both Ubuntu and Debian developers. When changing the source and method of delivering applications to users, it will be important to keep the user informed about what they are installing, who is providing it, and the possible side affects it may cause.

Indicate Source

There are several places where an Ubuntu user will see the availability of an application. Before selecting an application to install or version to upgrade, the user will be informed, as much as possible, about the provider of the packages and the level of support provided.

The Web Catalog (apps.ubuntu.com) will also be used to identify the provider of the different available versions of an application. For versions of an application in the distro archives, the web catalog will indicate that the version is provided by the Ubuntu project. For applications in the Extras archive, the web catalog will indicate that the software is provided by the upstream author or project.

When an application crash is detected, and if the application was installed from either the distro archives or the Extras archive, Apport will display a dialog asking the user if they would like to report the crash. If the installed application is from the distro archives, Apport will indicate that the error was from an Ubuntu provided package. If the installed application is from the Extras archive, Apport will indicate that the error was from a package provided by the upstream author or project. In addition, when the version of the application is provided by the upstream author or project, the user will be warned that the crash details being collected will be seen by the upstream author or project if submitted.

Indicate Access

In addition informing the user about the source of an application, they will need to be informed about the level of access being given to the application in its AppArmor profile.

MyApps will provide an API with information about the security policy options for each application published to the Extras archive. This list will be limited to the optional, non-runtime security access options from the 3rd list in the AppArmor Creation section above.

The Ubuntu Software Center will use the MyApps API to present the user with a list of policies being requested by an application they wish to install. If the application is requesting one or more of these options, Software Center will prompt the user to accept them before the application is installed.

If the user has defined a custom security profile for their system, Software Center will check to see whether an application from Extras is requesting access to one or more resources that has been denied in the user's profile. If so, Software Center will inform the user that the application violates their custom profile, and provide an option to make an exception for the application in question in order to allow its installation.

The Update Manager will also use the MyApps API to see if a newer version of a package is going to access one or more resources that the currently installed version did not. When this happens, Update Manager will de-select and disable the package from its upgrade list, and direct the user (with a link or button) to the Software Center so that they can view and approve the new security policy options before upgrading the package.

Work Items

The following tables list the high-level work items that are required to implement this specification.

App Preparation

/opt/ Build Relocation

Developer Request

Security Policy Preparation

1. handled by Mir on Ubuntu Touch. X mediation (ie for Ubuntu Desktop) not scheduled for 13.10
2. not required for SDK apps in 13.10

App Review

Upload

Extras Archive

Visibility

¹ This is no longer a requirement

Feedback

If you have got an interest in making Ubuntu a target platform for app developers and would like to contribute to the specification with your input, please give us some feedback >.